Bug 27241 - MappingNotify and keyboards with pointer capabilities
Summary: MappingNotify and keyboards with pointer capabilities
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Input/Core (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Peter Hutterer
QA Contact: Xorg Project Team
Depends on:
Reported: 2010-03-22 07:35 UTC by Rami Ylimaki
Modified: 2016-11-28 04:40 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Note You need to log in before you can comment on or make changes to this bug.
Description Rami Ylimaki 2010-03-22 07:35:46 UTC
Let X server detect the Logitech MX5500 keyboard. This is a true keyboard but is attached to Virtual core pointer in EnableDevice because it has some pointer capabilities.

Set up different keyboard mappings for your main keyboard and MX5500. Launch xev and type keys on both keyboards. Expected result is to get MappingNotify when changing between the keyboards. Actual result is that pressing keys on MX5500 don't produce MappingNotify and the wrong main keyboard layout is used.

This is caused by the fact that mieqProcessDeviceEvent forces the master device to be Virtual core keyboard for master key events. The slave master device and dce master devices don't match in ChangeMasterDeviceClasses when master key events are processed and therefore MappingNotify isn't sent.

It's unclear to me whether this should be fixed by allowing the sending of MappingNotify events or by attaching MX5500 to Virtual core keyboard. I guess it's impossible to determine in the general case whether an input device is a pointer or a keyboard so it looks like the sending of MappingNotify should be fixed for pointers as well.

The problem is especially annoying with MX5500 because it is a keyboard with only keys on it and no way to use it as a pointer.

# /lib/udev/input_id class/input/event10

# xinput list-props 8
Device '"Logitech MX5500 Keyboard"':
	Device Enabled (136):	1
	Device Accel Profile (261):	0
	Device Accel Constant Deceleration (262):	1.000000
	Device Accel Adaptive Deceleration (264):	1.000000
	Device Accel Velocity Scaling (265):	10.000000
	Evdev Axis Inversion (266):	0, 0
	Evdev Axis Calibration (267):	<no items>
	Evdev Axes Swap (268):	0
	Axis Labels (269):	"Abs Volume" (287), "None" (0), "None" (0), "None" (0)
	Button Labels (270):	"Button 0" (286), "Button Unknown" (258), "Button Unknown" (258), "Button Wheel Up" (140), "Button Wheel Down" (141), "Button Horiz Wheel Left" (142), "Button Horiz Wheel Right" (143)
	Evdev Middle Button Emulation (271):	2
	Evdev Middle Button Timeout (272):	50
	Evdev Wheel Emulation (273):	0
	Evdev Wheel Emulation Axes (274):	0, 0, 4, 5
	Evdev Wheel Emulation Inertia (275):	10
	Evdev Wheel Emulation Timeout (276):	200
	Evdev Wheel Emulation Button (277):	4
	Evdev Drag Lock Buttons (278):	0
Comment 1 Rami Ylimaki 2010-04-14 01:22:47 UTC
Any comments? Do you think that keyboards with pointer capabilities should sent MappinNotify?
Comment 2 Daniel Stone 2010-04-14 07:38:28 UTC
On Wed, Apr 14, 2010 at 01:22:46AM -0700, bugzilla-daemon@freedesktop.org wrote:
> --- Comment #1 from Rami Ylimaki <rami.ylimaki@vincit.fi> 2010-04-14 01:22:47 PDT ---
> Any comments? Do you think that keyboards with pointer capabilities should sent
> MappinNotify?

Yeah, this is definitely a bug - MappingNotify should be sent.  I
actually have one of these keyboards in a box somewhere, so hopefully
I'll take a look at this soon ...
Comment 3 Al Scandar Solstag 2010-10-19 02:12:14 UTC

I believe I may be suffering from a different symptom of this same problem, however I'm not entirely certain.

Would this cause gnome-keyboard-properties to have no effect on the MX5500's input, yet running setxkbmap (like simply "setxkbmap pt_intl") works?

Sorry if this is a different issue, I can't find an explanation for my problem and this is the closest I've seen. If I'm wrong let me know so I can file a bug for GNOME.

Thanks and if there's any testing that could help (even if it's not my issue) please ask.

Comment 4 Rami Ylimaki 2010-10-19 03:16:04 UTC
(In reply to comment #3)
> Would this cause gnome-keyboard-properties to have no effect on the MX5500's
> input, yet running setxkbmap (like simply "setxkbmap pt_intl") works?

This original problem is (or was, haven't checked if it works now) about using two keyboards simultaneously with different layouts.

I just checked gnome-keyboard-properties and it can be used to set the MX5500 layout correctly, provided that you are only using a single layout for all of your keyboards.

However, the gnome-keyboard-properties is not so intuitive. Let me explain how I made it work. By default I only have one layout in gnome-keyboard-properties: Finnish (*). I added a new layout and set it as default: Finnish (), USA (*). Still my keyboard has Finnish layout, because gnome configured has Finnish as the primary layout (primary group) and USA as secondary layout (group). If I change the order of layouts in gnome-keyboard-properties by dragging USA on top of Finnish, the USA layout is activated: USA (*), Finnish ().

How many layouts have you configured in gnome-keyboard-properties and what is their order? What is the output of setxkbmap -print before your modifications in gnome-keyboard-properties? What is the output after your changes? I strongly believe your problem is just a gnome issue.
Comment 5 Peter Hutterer 2016-11-28 04:40:03 UTC
This is a mass change of bugs. Bugs assigned to me that haven't been updated in the last 3 years are closed as WONTFIX, because, well, let's at least be honest about it.

Please do not re-open unless you have a really good reason to do so (e.g. you're fixing it yourself). If it hasn't been fixed in the last 3 years, it probably won't be fixed anytime soon either. Sorry.

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.