Bug 19048 - xserver 1.5.99.3 fails to set the correct layout
Summary: xserver 1.5.99.3 fails to set the correct layout
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Keith Packard
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
: 19033 19222 19345 (view as bug list)
Depends on:
Blocks: xserver-1.6
  Show dependency treegraph
 
Reported: 2008-12-12 09:42 UTC by Timo Aaltonen
Modified: 2018-06-11 20:03 UTC (History)
8 users (show)

See Also:
i915 platform:
i915 features:


Attachments
0001-mi-force-CopyKeyClass-for-key-events.-19048.patch (1.88 KB, patch)
2008-12-14 17:13 UTC, Peter Hutterer
no flags Details | Splinter Review
Update ctrls too (1.47 KB, patch)
2008-12-29 04:20 UTC, Sascha Hlusiak
no flags Details | Splinter Review
0001-mi-force-CopyKeyClass-for-key-events.-19048.patch (2.09 KB, patch)
2009-01-12 00:32 UTC, Peter Hutterer
no flags Details | Splinter Review

Description Timo Aaltonen 2008-12-12 09:42:47 UTC
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.
Comment 1 Peter Hutterer 2008-12-14 16:11:40 UTC
sorry for the change, firefox plugin gone nuts.
Comment 2 Peter Hutterer 2008-12-14 17:13:12 UTC
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?
Comment 3 Timo Aaltonen 2008-12-14 23:28:33 UTC
Yes, works!
Comment 4 Peter Hutterer 2008-12-17 15:56:41 UTC
Reassigning to Keith, ball is in his court now to apply it to 1.6.
Comment 5 Peter Hutterer 2008-12-18 02:32:52 UTC
*** Bug 19033 has been marked as a duplicate of this bug. ***
Comment 6 Colin Guthrie 2008-12-28 06:01:43 UTC
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 :))
Comment 7 Sascha Hlusiak 2008-12-28 09:26:52 UTC
(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.
Comment 8 Daniel Stone 2008-12-28 18:34:59 UTC
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.
Comment 9 Peter Hutterer 2008-12-28 23:20:19 UTC
(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.


Comment 10 Sascha Hlusiak 2008-12-29 04:20:19 UTC
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.
Comment 11 Daniel Stone 2008-12-29 05:07:03 UTC
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?
Comment 12 Daniel Stone 2008-12-29 05:34:59 UTC
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?
Comment 13 Sascha Hlusiak 2008-12-29 14:39:28 UTC
(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.

Comment 14 Daniel Stone 2008-12-29 15:27:40 UTC
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.
Comment 15 Daniel Stone 2008-12-29 17:21:20 UTC
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.
Comment 16 Timo Aaltonen 2008-12-31 01:41:10 UTC
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"
Comment 17 Peter Hutterer 2009-01-12 00:32:13 UTC
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.
Comment 18 Peter Hutterer 2009-01-12 00:32:58 UTC
Reopening too, this patch is still waiting to be cherry-picked.
Comment 19 Peter Hutterer 2009-01-12 00:36:07 UTC
*** Bug 19222 has been marked as a duplicate of this bug. ***
Comment 20 Keith Packard 2009-01-12 10:58:53 UTC
The fixes are all cherry-picked to server-1.6-branch now.
Comment 21 Adam Jackson 2018-06-11 20:03:22 UTC
*** 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.