Bug 98998 - evdev: Define more Input API symbols
Summary: evdev: Define more Input API symbols
Status: RESOLVED DUPLICATE of bug 11227
Alias: None
Product: xorg
Classification: Unclassified
Component: Input/evdev (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Peter Hutterer
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-05 12:34 UTC by Jan-Benedict Glaw
Modified: 2016-12-05 20:48 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan-Benedict Glaw 2016-12-05 12:34:50 UTC
Hi!

Using Linux's User Input API interface to implement an input device from userland, we supported some non-standard RCs. These have some multimedia keys (TV, Radio, Music, Video, WWW), which I mapped to Linux's proper key definitions.

However, Xorg's evdev input driver doesn't understand those. As far as I see, the evdev device node is found and used, using the mappings read from /usr/share/X11/xkb/keycodes/evdev on an up-to-date Debian-based distribution. The mentioned keys don't exist there, and defining them (with the magic offset of 8) didn't help, but lead to errors during X11 start-up.

I'd like to understand what's happening here. From https://bugs.freedesktop.org/show_bug.cgi?id=12202 it seems that the X11 protocol does only have one 8bit byte for keycodes, so supporting Linux's hugh number of Input API keycodes (about 540) just won't work?

Or is there a way to assign those "scan"codes to X11 names?

Thanks,
  Jan-Benedict
Comment 1 Peter Hutterer 2016-12-05 20:48:28 UTC
not easily. you'd have to set up some mapping table between high scancodes and map them into (unused) lower scancodes within the driver, before passing them to the server. Then you need a keyboard layout that knows about this mapping. This is a bit fiddly but it can be done as long as you control both the driver and the layout applied on the system (which we don't).

also, evdev doesn't really care about whether the code is defined or not, it'll just forward most of them as-is (with the +8). Then that code is sent to the client who looks it up in the XKB table and converts it to a glyph if applicable.

see also:
http://who-t.blogspot.com.au/2014/12/why-255-keycode-limit-in-x-is-real.html

*** This bug has been marked as a duplicate of bug 11227 ***


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.