I've packaged xserver 1.5.99.3 and upgraded my laptop, and the result is that the layout is 'us' even though setxkbmap -print shows the right one: xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+fi+inet(evdev)+level3(ralt_switch)" }; xkb_geometry { include "pc(pc105)" }; }; and the logfile says that the driver is using the correct options. the server has these patches on top of beta3 from the proposed queue: Xi: don't update VCP's valuators from DeviceValuator events #18882 xkb: Allow NULL as rulesFile in XkbSetRulesDflts. Let the DDX decide on the XkbRulesDefaults. I've tried dropping the last two, no change.
sorry for the change, firefox plugin gone nuts.
Created attachment 21140 [details] [review] 0001-mi-force-CopyKeyClass-for-key-events.-19048.patch Calling CopyKeyClass from mieqProcessInputEvents does the trick. This is basically what SwitchCoreKeyboard used to do in 1.5. Can you please test that?
Yes, works!
Reassigning to Keith, ball is in his court now to apply it to 1.6.
*** Bug 19033 has been marked as a duplicate of this bug. ***
Peter, I thought the general process was to apply this to master then to post on the 1.6 wiki page to request a merge? So, should this not go into master first? (granted this bug is a blocker so it shouldn't be lost but all the same :))
(In reply to comment #2) > Created an attachment (id=21140) [details] > 0001-mi-force-CopyKeyClass-for-key-events.-19048.patch > > Calling CopyKeyClass from mieqProcessInputEvents does the trick. This is > basically what SwitchCoreKeyboard used to do in 1.5. Can you please test that? > Are you sure it copies everything? After applying the patch, the layout switch does work, but my Left/Down keys does not autorepeat. That reminds me of a bug long time ago, when the autorepeat masks were still at the standard layout, where the scancode of the Left key was one of a modifier. And the ISO_Level3_Shift, Super_L and Super_R modifier keys do autorepeat, which they should not.
On Sun, Dec 28, 2008 at 09:26:53AM -0800, bugzilla-daemon@freedesktop.org wrote: > --- Comment #7 from Sascha Hlusiak <bugs@saschahlusiak.de> 2008-12-28 09:26:52 PST --- > (In reply to comment #2) > > Created an attachment (id=21140) > --> (http://bugs.freedesktop.org/attachment.cgi?id=21140) [details] > > 0001-mi-force-CopyKeyClass-for-key-events.-19048.patch > > > > Calling CopyKeyClass from mieqProcessInputEvents does the trick. This is > > basically what SwitchCoreKeyboard used to do in 1.5. Can you please test that? > > Are you sure it copies everything? After applying the patch, the layout switch > does work, but my Left/Down keys does not autorepeat. That reminds me of a bug > long time ago, when the autorepeat masks were still at the standard layout, > where the scancode of the Left key was one of a modifier. > > And the ISO_Level3_Shift, Super_L and Super_R modifier keys do autorepeat, > which they should not. Does either or both of: http://people.freedesktop.org/~daniels/copykeyclass-call-ctrlproc-for-feedbacks.diff http://people.freedesktop.org/~daniels/xkbcopykeymap-update-ctrls-too.diff help at all? Not even compile-tested, but you get the idea. It's horrifically ugly, but as with all other input problems/cancer/NP-complete problems, it's all fixed in xkb-atkins.
(In reply to comment #6) > Peter, I thought the general process was to apply this to master then to post > on the 1.6 wiki page to request a merge? So, should this not go into master > first? (granted this bug is a blocker so it shouldn't be lost but all the same > :)) server 1.6 needs special treatment here so we can't put that into master. master does the right job already by copying the whole device into the MD. 1.6 can't do that as some parts of the device must be immutable for core compatibility. This is the problem with this bug and the call to CopyKeyClass may not be enough for this reason. I need to find time to figure this out, we need a DeepCopyDeviceClasses, but more restrictive (it mustn't change button numbers, axis ranges, etc). Daniel, if you know what exactly to copy - much appreciated. (In reply to comment #8) > Does either or both of: > http://people.freedesktop.org/~daniels/copykeyclass-call-ctrlproc-for-feedbacks.diff DeepCopyFeedbackClasses isn't called in 1.6, so this patch has no effect. Seems like something for master though.
Created attachment 21546 [details] [review] Update ctrls too Compile fixed http://people.freedesktop.org/~daniels/xkbcopykeymap-update-ctrls-too.diff The attached patch fixes it indeed.
On Sun, Dec 28, 2008 at 11:20:22PM -0800, bugzilla-daemon@freedesktop.org wrote: > --- Comment #9 from Peter Hutterer <peter.hutterer@who-t.net> 2008-12-28 23:20:19 PST --- > (In reply to comment #6) > > Peter, I thought the general process was to apply this to master then to post > > on the 1.6 wiki page to request a merge? So, should this not go into master > > first? (granted this bug is a blocker so it shouldn't be lost but all the same > > :)) > > server 1.6 needs special treatment here so we can't put that into master. > master does the right job already by copying the whole device into the MD. 1.6 > can't do that as some parts of the device must be immutable for core > compatibility. This is the problem with this bug and the call to CopyKeyClass > may not be enough for this reason. > I need to find time to figure this out, we need a DeepCopyDeviceClasses, but > more restrictive (it mustn't change button numbers, axis ranges, etc). > Daniel, if you know what exactly to copy - much appreciated. > > (In reply to comment #8) > > Does either or both of: > > http://people.freedesktop.org/~daniels/copykeyclass-call-ctrlproc-for-feedbacks.diff > > DeepCopyFeedbackClasses isn't called in 1.6, so this patch has no effect. Seems > like something for master though. Actually, thinking about it, this is going to be slightly problematic, as calling CtrlProc will update the LEDs for all devices using that MD. I think maybe we should just update kbdfeed in-place and not call CtrlProc?
On Mon, Dec 29, 2008 at 04:20:22AM -0800, bugzilla-daemon@freedesktop.org wrote: > --- Comment #10 from Sascha Hlusiak <bugs@saschahlusiak.de> 2008-12-29 04:20:19 PST --- > Created an attachment (id=21546) > --> (http://bugs.freedesktop.org/attachment.cgi?id=21546) > Update ctrls too > > Compile fixed > http://people.freedesktop.org/~daniels/xkbcopykeymap-update-ctrls-too.diff > > The attached patch fixes it indeed. Cool, thanks. Does it still work if you take out the CtrlProc call?
(In reply to comment #12) > > The attached patch fixes it indeed. > > Cool, thanks. Does it still work if you take out the CtrlProc call? It indeed still works without the CtrlProc call, yes.
On Mon, Dec 29, 2008 at 02:39:29PM -0800, bugzilla-daemon@freedesktop.org wrote: > --- Comment #13 from Sascha Hlusiak <bugs@saschahlusiak.de> 2008-12-29 14:39:28 PST --- > (In reply to comment #12) > > > The attached patch fixes it indeed. > > > > Cool, thanks. Does it still work if you take out the CtrlProc call? > > It indeed still works without the CtrlProc call, yes. Cool, I'll commit that then. Thanks.
On Mon, Dec 29, 2008 at 03:27:40PM -0800, bugzilla-daemon@freedesktop.org wrote: > Cool, I'll commit that then. Thanks. Oops, forgot the bug reference, but it's fixed with 48dbaf.
by the way, the original patch seems to cause bug 19222. From the ubuntu bug: "Pressing any key in onboard crashes xserver with SIGSEGV in CopyKeyClass" https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/309785 "This problem is probably caused by 154_force-copykeyclass-for-key-events.patch of xserver-xorg-core. The patch adds ChangeDeviceID(mdev, *master); to CopyKeyClass but doesn't check if master is valid. Master is NULL in the backtrace, so I guess it segfaults right there. Luckily there is already a fresh upstream bug report assigned to the patch author: http://bugs.freedesktop.org/show_bug.cgi?id=19222"
Created attachment 21892 [details] [review] 0001-mi-force-CopyKeyClass-for-key-events.-19048.patch Ok, I just realized that having a follow-up patch in bugzilla for a patch that hasn't been committed yet (Bug 19222) doesn't really make sense, so I rebased and squashed the two. This patch fixes Bug 19048 and Bug 19222, the fix being courtesy by Colin Guthrie.
Reopening too, this patch is still waiting to be cherry-picked.
*** Bug 19222 has been marked as a duplicate of this bug. ***
The fixes are all cherry-picked to server-1.6-branch now.
*** Bug 19345 has been marked as a duplicate of this bug. ***
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.