Your message dated Fri, 22 Apr 2022 15:04:06 +0200 with message-id <YmKnxozRahmoB2Ks@jcristau-z4> and subject line Re: Bug#661754: x11-xkb-utils: setxkbmap and xkbcomp settings do not apply to new keyboards has caused the Debian Bug report #661754, regarding x11-xkb-utils: setxkbmap and xkbcomp settings do not apply to new keyboards 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 [email protected] immediately.) -- 661754: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661754 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: x11-xkb-utils Version: 7.6+4 Severity: important Dear Maintainer, My desktop can finally suspend and resume properly, which makes me very happy, but let me discover a new obstacle: upon resume my keybard settings are lost and I have to re-apply my xkbcomp setting every time. The same can be seen without suspend&resume: % setxkbmap -model 'thinkpad(60)' % setxkbmap -query rules: evdev model: thinkpad(60) layout: us % <unplug the (USB) keyboard, and plug it back in> % setxkbmap -query rules: evdev model: pc105 layout: us % It seems that setxkbmap only affects the current InputDevice, whereas I'd like to affect a whole InputClass, but I don't know how/where to specify which inputs devices should be affected. Where are the equivalent of xorg.conf's MatchIsKeyboard/MatchProduct/...? Tho to tell you the truth, I don't need to distinguish input devices, all I want is for my settings to apply to *all* keyboards (which is only ever a single keyboard but which might get unplugged/replugged). Stefan *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 3.2.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages x11-xkb-utils depends on: ii libc6 2.13-26 ii libx11-6 2:1.4.4-4 ii libxaw7 2:1.0.9-3 ii libxkbfile1 1:1.0.7-1 ii libxt6 1:1.1.1-2 x11-xkb-utils recommends no packages. x11-xkb-utils suggests no packages. -- no debconf information
--- End Message ---
--- Begin Message ---On Thu, Mar 01, 2012 at 05:13:44PM -0500, Stefan Monnier wrote: > > Oh, I'm not saying it's possible today, I'm saying it's where it should > > be happening (it knows when a device gets plugged in, it has some > > knowledge of input device configuration, so making that per-device > > should be possible). If gsd isn't suitable, it shouldn't be too hard to > > write a program listening for DevicePresence events and doing whatever > > config is necessary for new devices. > > That seems way too complicated: the X server already has the notion of > an InputClass section and setxkbmap is already a way to dynamically > specify an InputDevice section, so all that's needed is a way to > pass dynamically to the X server an InputClass section. > It seems like this bug has become a feature request for the Xorg server, so doesn't belong on the Debian bug tracker for x11-xkb-utils. Closing. Feel free to submit the request upstream, ideally with a patch if you want to see it happen. Or it may already exist in your wayland compositor of choice. Cheers, Julien
--- End Message ---
