Bug#823214: xserver-xorg-input-libinput: InputClass Options ignored after upgrade
Adding Driver "evdev" to the InputClass gets me back to the pre-upgrade state. Thanks for the tip. If upstream are interested in fixing the bug / adding support for those options, I'd be happy to help them get to the bottom of it by providing them with diagnostic information, but they'll have to let me know exactly what commands to type. I turn the trackball upside down to fit between the parts of my Kinesis Advantage keyboard. Note that the button remapping is also ignored, not just the axis inversions. ... oh, none of this thread is going to the debian bug tracker is it?
Bug#823214: xserver-xorg-input-libinput: InputClass Options ignored after upgrade
Package: xserver-xorg-input-libinput Version: 0.18.0-1 Severity: grave Justification: renders package unusable Dear Maintainer, I did a routine upgrade of my apt packages, this is what I believe was the relevant part of the /var/log/apt/term.log Selecting previously unselected package xserver-xorg-input-libinput. Preparing to unpack .../xserver-xorg-input-libinput_0.18.0-1_amd64.deb ... Unpacking xserver-xorg-input-libinput (0.18.0-1) ... Preparing to unpack .../xserver-xorg-input-all_1%3a7.7+15_amd64.deb ... Unpacking xserver-xorg-input-all (1:7.7+15) over (1:7.7+14) ... Processing triggers for libc-bin (2.22-7) ... Processing triggers for man-db (2.7.5-1) ... Processing triggers for initramfs-tools (0.125) ... update-initramfs: Generating /boot/initrd.img-4.5.0-1-amd64 Setting up btrfs-progs (4.4.1-1.1) ... Setting up xserver-xorg-input-libinput (0.18.0-1) ... Setting up xserver-xorg-input-all (1:7.7+15) ... After the upgrade, my input device options were ignored and I was unable to use my device. This is the relevant part of my /etc/x11/xorg.conf Section "InputClass" Identifier "Kensington" MatchProduct"Kensington Kensington Slimblade Trackball" Option "InvertX" "on" Option "InvertY" "on" Option "ButtonMapping" "9 3 8 4 5 6 7 1 2" EndSection reportbug has a attached various logs, I cannot see anything relevant in there to suggest what could have broken this. My workaround is to use an old mouse that I have, I'll set my trackpad aside. Please let me know if there is any further information that you require. I'm going to try and track down version 1:7.7+14 of the above packages, if you have a link to them it would be greatly appreciated. I'll report back if downgrading helps. If this was Java, Scala or lisp related, I could dig into the details and send you a fix, but unfortunately my understanding of the X11 / input layer (and C in general) is extremely poor. Best regards, Sam -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Mar 22 2014 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 274 Apr 5 08:05 /usr/bin/Xorg Diversions concerning libGL are in place diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/libGLESv2.so to /usr/lib/mesa-diverted/libGLESv2.so by glx-diversions diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to /usr/lib/mesa-diverted/arm-
Bug#256442: [ATTACHED] iBook G4 British keymap
Branden Robinson wrote: > On Wed, Jul 14, 2004 at 02:48:52PM +0100, Sam Halliday wrote: > > > Try commenting out the XkbOptions line altogether. > > > > > > For an Apple Pro keyboard, model M7803, and using the following > > > configuration: > > > > > > XkbRules xfree86 > > > XkbModel macintosh > > > XkbLayout us > > > > > > This puts: > > > Ctrl_L on the left control key > > > Alt_L on the left Option/Alt key > > > Super_L on the left Apple/Command key > > > Super_R on the right Apple/Command key > > > Alt_R on the right Option/Alt key > > > Ctrl_R on the right control key > > > > yes... but the key marked "alt" on an apple keyboard should actually be > > "altgr". go into MacOS X and see for yourself... > > > > so it should be: > > Ctrl_L on the left control key > > Super_L on the left Option/Alt key > > Alt_L on the left Apple/Command key > > Alt_R on the right Apple/Command key > > Super_R on the right Option/Alt key > > Ctrl_R on the right control key > > > > it seems silly to have Debian and MacOS disagree about what the keymapping > > should be. > > I think it's sillier for keys to not do what's engraved on them. what about mouse buttons then? the mac mouse only has one mouse button... is it a left or a right mouse button? the left mouse button is chosen as it is the most compatible with what happens under MacOS X (and also the most sensible option, and probably sends the same signal...). ok, maybe thats a crap example :-) > I am not opposed to having an XkbOption called "altwin:macosx", for > example, for people who seek Mac OS X compatibility, but I am skeptical > that this should be the default. i like this. how can it be implemented? cheers, Sam -- Free High School Science Texts http://www.nongnu.org/fhsst/ Sam's Homepages http://fommil.homeunix.org/~samuel/ http://www.ma.hw.ac.uk/~samuel/ pgpuh83oz2xqQ.pgp Description: PGP signature
Bug#256442: [ATTACHED] iBook G4 British keymap
> Try commenting out the XkbOptions line altogether. > > For an Apple Pro keyboard, model M7803, and using the following > configuration: > > XkbRules xfree86 > XkbModel macintosh > XkbLayout us > > This puts: > Ctrl_L on the left control key > Alt_L on the left Option/Alt key > Super_L on the left Apple/Command key > Super_R on the right Apple/Command key > Alt_R on the right Option/Alt key > Ctrl_R on the right control key yes... but the key marked "alt" on an apple keyboard should actually be "altgr". go into MacOS X and see for yourself... so it should be: Ctrl_L on the left control key Super_L on the left Option/Alt key Alt_L on the left Apple/Command key Alt_R on the right Apple/Command key Super_R on the right Option/Alt key Ctrl_R on the right control key it seems silly to have Debian and MacOS disagree about what the keymapping should be. cheers, Sam -- Free High School Science Texts http://www.nongnu.org/fhsst/ Sam's Homepages http://fommil.homeunix.org/~samuel/ http://www.ma.hw.ac.uk/~samuel/ pgpAQknRY3mmF.pgp Description: PGP signature
Bug#256442: [ATTACHED] iBook G4 British keymap
Sam Halliday wrote: > Branden Robinson wrote: > > In that case it sounds like this problem would be resolved for the > > submitter by using the following configuration: > > > > XkbRulesxfree86 > > XkbModelmacintosh > > XkbLayout gb > > XkbOptions grp:lwin_switch,compose:rwin > > > > Does any one object to me closing this bug? > > nope, that works for me. damn... sorry, this is still nto working; i don't know why it worked a minute ago (i think i forgot to restart X). now the alt and altgr keys are the wrong way round. how can i swap them in the XF86Config file? i do not wish to use xmodmap. pgp4CO23k3Kam.pgp Description: PGP signature
Bug#256442: [ATTACHED] iBook G4 British keymap
Branden Robinson wrote: > In that case it sounds like this problem would be resolved for the > submitter by using the following configuration: > > XkbRules xfree86 > XkbModel macintosh > XkbLayout gb > XkbOptionsgrp:lwin_switch,compose:rwin > > Does any one object to me closing this bug? nope, that works for me. sorry for adding to the confusion!! i think i was chatting to some people who *thought* they had a british mac keyboard, but actually had an american one. confused the `zig' out of me :-) although... one small gripe; the shift-return and standalone key which has marked _ ^ (i don't know if there is a font for that) is producing i never use that key, so it doesn't bother me... but just to let you know the story isn't complete yet ;-) cheers, Sam -- Free High School Science Texts http://www.nongnu.org/fhsst/ Sam's Homepages http://fommil.homeunix.org/~samuel/ http://www.ma.hw.ac.uk/~samuel/ pgpOtmxXaGrU6.pgp Description: PGP signature
Bug#256442: [ATTACHED] iBook G4 British keymap
Branden Robinson wrote:
> I don't see many differences between this and the current
> /etc/X11/xkb/symbols/macintosh/gb file, which I fixed up in xlibs
> 4.3.0.dfsg.1-5:
this is what is different:
// let the marked "alt" be AltGr (as it is in MacOS)
key { [ Mode_switch ] };
// let the Apple key be Alt
key { [ Alt_L] };
the key physically marked "alt" on a macintosh keyboard is actually altgr (as
can confirmed in MacOS X). The apple key should then be the alt key. this
mapping does that.
this keymap is still unfinished... numlock stuff is still undefined/broken. i
might do that one day... but given how long it has been before people have asked
for a keymap doing what is actually physically written on the keys; i'd expect
the demand is low priority.
cheers,
Sam
--
Free High School Science Texts
http://www.nongnu.org/fhsst/
Sam's Homepages
http://fommil.homeunix.org/~samuel/
http://www.ma.hw.ac.uk/~samuel/
pgpHdVhihE6Sd.pgp
Description: PGP signature
Bug#256442: iBook G4 British keymap
Sam Halliday wrote: > i just noticed bug #201737... before anyone goes and tries to combine this bug > with that one... THEY ARE NOT THE SAME. actually, they are the same bug... but i didn't notice previously as people seem prepared to use a half-complete keyboard map. the attached file i sent has a more complete set of key mappings. cheers, Sam -- Free High School Science Texts http://www.nongnu.org/fhsst/ Sam's Homepages http://fommil.homeunix.org/~samuel/ http://www.ma.hw.ac.uk/~samuel/ pgpu4L7e0uzwB.pgp Description: PGP signature
Bug#256442: iBook G4 British keymap
hi there, i just noticed bug #201737... before anyone goes and tries to combine this bug with that one... THEY ARE NOT THE SAME. in that bug, the problem is that the # key does not work... but the real problem is totally overlooked. the actual keyboard mapping (as a whole) is missing! for example... in the top left of my keyboard i have a key which generates §±, beside left shift the key does `~... the solution posed in that bug does not fix these as it is a totally different keymapping all together. apple have a NEW british keymap, and this is the mapping for it. everyone trying to fix the old gb map is messing with a keymapping which may actually work fine on older machines. cheers, Sam -- Free High School Science Texts http://www.nongnu.org/fhsst/ Sam's Homepages http://fommil.homeunix.org/~samuel/ http://www.ma.hw.ac.uk/~samuel/ pgpUMTQ6oopl6.pgp Description: PGP signature
Bug#256442: [ATTACHED] iBook G4 British keymap
Package: xlibs Version: 4.3.0.dfsg.1-5 it would appear Apple are using new designs for the british keyboards on iBooks and Powerbooks. i save the attached file as /usr/X11R6/lib/X11/xkb/symbols/macintosh/gb_new an annoying thing about this new Apple keyboard is that the # key is not marked physically on any of the keys. it is bound in MacOS to AltGr+3 (even though AltGr is marked as "alt" physically on the keyboard) i have had this setup working in all X applications for extended Latin-9 characters (such as §±¤) in MacOS, every key seems to have an AltGr binding... i did not have time to create the full table for all the keys. this is just created from the keys which are physically marked on the keyboard, plus ¢ and #. i have sent an accompanying file to the console-data package for console support. gb_new Description: Binary data pgp6cJbrgyU00.pgp Description: PGP signature
