| |||||||||||||
GNOME Shell, extensions, and controlGNOME Shell, extensions, and controlPosted Jun 23, 2011 14:49 UTC (Thu) by nix (subscriber, #2304)In reply to: GNOME Shell, extensions, and control by mjg59 Parent article: GNOME Shell, extensions, and control
Ah, that's different, of course. Scancode 1 on standard PCs sends ESC, always. I've never seen a keyboard for which that was different, so why you didn't simply say 'use ESC' is beyond me.
(Log in to post comments)
GNOME Shell, extensions, and control Posted Jun 23, 2011 14:56 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
Sorry, 41, not 1.
GNOME Shell, extensions, and control Posted Jun 23, 2011 18:21 UTC (Thu) by nix (subscriber, #2304) [Link]
Well, what that is depends on what scancode set you're using. In set 1, scancode 41 is the key labelled 1/!; in set 2, the key labelled ,/<; in USB, it is escape. However, you can't easily get scancodes directly from X, so I don't see how you've implemented this without going below X completely. On most UK keyboards at least, the key above tab has the backtick and strange alternative pipe symbol on it, which X shows as keycode 49 unless shifted. That's another reason why this should be avoided: the scancode->keycode mapping varies, often radically, between national keyboard layouts.
More generally, the whole area of scancodes is a confusing and ill-thought-out mess replete with historical horrors, best avoided. At this point I have no idea *where* GNOME Shell gets its codes from, and no clue what key is used for this feature at all, only that the key above tab doesn't generate any of the codes you've suggested (not scancodes, nor X keycodes) on any keyboard I have access to, conventional or not. I'd have to look at the code... (I'm fairly sure it's not actually using scancodes, though, because that would require raw access. Are you talking about X keycodes? They're quite different.)
Why not just make this stuff an option so people can set a key and know what it is without having to go through all this trouble? Or use a keysym like every single other X app since the dawn of time?
GNOME Shell, extensions, and control Posted Jun 23, 2011 18:27 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
The scancode->keycode mapping is fixed in Linux now, assuming you're using evdev (and if you're not you're doing it very wrong). X keycodes are simply the Linux scancodes plus 8 for historic reasons. You can't use a keysym because then the key moves around the keyboard, and the desire is for it to retain some degree of spatial locality to the tab key. The default can be overridden in the settings.
GNOME Shell, extensions, and control Posted Jun 23, 2011 21:26 UTC (Thu) by nix (subscriber, #2304) [Link]
Ah, so this is evdev-specific? That explains things: I have substantial Xkb customizations and so far haven't got around to rejigging them for evdev (not least because the last three times I tried to start X using evdev as the keyboard driver I ended up with no keyboard at all: the next time I try it I think I'll track it down far enough to report a bug rather than pathetically giving up and going back to kbd).
If the default can be overridden, then I have no complaints: most users *are* indeed using evdev (even users of obscure keyboards): that I am not is entirely my own damn fault.
|
|||||||||||||