[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#673028: marked as done (xkbcomp doesn't install key repeat state)

Your message dated Fri, 22 Apr 2022 15:08:43 +0200
with message-id <YmKo2wCwB76xt+CD@jcristau-z4>
and subject line Re: Bug#673028: xkbcomp doesn't install key repeat state
has caused the Debian Bug report #673028,
regarding xkbcomp doesn't install key repeat state
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
673028: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673028
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: x11-xkb-utils
Version: 7.5+5
Severity: important

Whether a key is eligible to auto-repeat can be specified in XKB source,
using the key.repeat property.  xkbcomp processes this, preserving it in
a compiled .xkm file and regurgitating it when decompiling a .xkm back to
.xkb source.  However, when it's asked to install a keymap, by giving it
a display as a target, it doesn't install the per-key repeat property.
Instead, the keys retain the repeat state that they previously had.
Working around this requires use of "xset r" and "xset -r" to separately
set the repeat flag for each keycode.

When xkbcomp is asked to read the keymap state back from a display,
it correctly reflects the effective per-key repeat state.  So "xkbcomp
t0.xkb $DISPLAY; xkbcomp $DISPLAY t1.xkb" yields t1.xkb showing repeat
states unrelated to those in t0.xkb, while in other respects showing
equivalent settings.

-zefram

--- End Message ---
--- Begin Message --- 
Control: severity -1 wishlist

On Tue, May 15, 2012 at 03:28:49PM +0100, Zefram wrote:
> Package: x11-xkb-utils
> Version: 7.5+5
> Severity: important
> 
> Whether a key is eligible to auto-repeat can be specified in XKB source,
> using the key.repeat property.  xkbcomp processes this, preserving it in
> a compiled .xkm file and regurgitating it when decompiling a .xkm back to
> .xkb source.  However, when it's asked to install a keymap, by giving it
> a display as a target, it doesn't install the per-key repeat property.
> Instead, the keys retain the repeat state that they previously had.
> Working around this requires use of "xset r" and "xset -r" to separately
> set the repeat flag for each keycode.
> 
> When xkbcomp is asked to read the keymap state back from a display,
> it correctly reflects the effective per-key repeat state.  So "xkbcomp
> t0.xkb $DISPLAY; xkbcomp $DISPLAY t1.xkb" yields t1.xkb showing repeat
> states unrelated to those in t0.xkb, while in other respects showing
> equivalent settings.
> 
This is a feature request for xkbcomp, which I doubt will happen at this
stage, but even if it does, would have to happen upstream, so I'm
closing this debian report.

Cheers,
Julien

--- End Message ---
Reply to: