Bug 63752 (suse48752)

Summary: NX (or knx?) does not recognize AltGr key combinations
Product: [openSUSE] SUSE Linux 10.1 Reporter: Joerg Reuter <jreuter>
Component: KDEAssignee: Stefan Dirsch <sndirsch>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Enhancement    
Priority: P5 - None CC: dmueller, eich, joe, kpfeifle, ms, sndirsch
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Found By: Other Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Joerg Reuter 2004-12-01 20:44:49 UTC
Trying to type any AltGR key combination in an NX session (for example, AltGr-Q)
does not produce the desired character ("@") but only the key pressed
additionally to AltGr ("q").
Comment 1 Joerg Reuter 2004-12-01 20:44:49 UTC
<!-- SBZ_reproduce  -->
Start knx, connect and try to create a "@" character with a German keyboard...
Comment 2 Stefan Dirsch 2004-12-01 21:37:39 UTC
Marcus, you still remember how you've fixed this problem? 
Comment 3 Marcus Schaefer 2004-12-01 22:49:39 UTC
I called setxkbmap after the session has been established but 
that's not a fix just a workaround 
Comment 4 Stefan Dirsch 2004-12-01 23:14:43 UTC
Thanks. This works. IMHO this is something, which should be handled by knx. 
Kurt? 
Comment 5 Stefan Dirsch 2004-12-01 23:15:53 UTC
NX --> knx 
Comment 6 Kurt Pfeifle 2004-12-02 00:15:06 UTC
I think this is a bug (even a recurring one) in a

 a) either the NX libraries,
 b) or in KDE in general,

not kNX specifically. Because it happened with the !M NX Client too in my former
KDE sessions. I have not yet tracked it down and dont have any time currently
either. What I found as workaround was; go to KDE Control Center ("kcontrol"),
keyboard layout settings (I always use the "Search" tab for fast-finding)
*inside* *the* *NX* *session*, where I then "Enable keyboard layouts". Then
select a 102-key or a 104- or 105-key layout (sorry, can't remember which) and
make that permanent. That is a permanent workaround for me and I am not missing
any key (but then, I am not an Emacs user-fingertwister...). 

AFAIR the problem doesnt occur in the "US layout" setting either....

Someone with more time should try to verify if this also occurs in a GNOME
session, or in a GNOME app started inside KDE, or in an Xterm. And then submit
the appropriate bug report to the correct addressee. I didnt.
Comment 7 Stefan Dirsch 2004-12-02 00:42:21 UTC
Thanks, Kurt. Jörg, could you please try this workaround? 
Comment 8 Joerg Reuter 2004-12-02 01:02:42 UTC
That works, thanks.
Comment 9 Stefan Dirsch 2004-12-02 01:22:55 UTC
I see this one in the log of KNX: 
 
knx: receivedFromSSH: startsession --session="baker"  --link="modem" 
--geometry="800x600+0+0" --type="unix-kde startsession --session="baker"  
--link="modem" --geometry="800x600+0+0" --type="unix-kde" --screeninfo="1152x8 
 
Therefore I think knx should also be able to transfer the current keyboard 
layout, but I have no idea how to detect the current keyboard layout ... 
Comment 10 Marcus Schaefer 2004-12-02 16:49:14 UTC
maybe this one can be used: 
 
 xkbctrl `cat /etc/sysconfig/keyboard |\ 
        grep ^KEYTABLE | cut -f 2 -d= |\ 
        tr -d \"` | grep Apply | cut -f2 -d: 
Comment 11 Stefan Dirsch 2004-12-02 20:05:42 UTC
Thanks. This should work in many cases (in a SuSE environment). But it should 
be configurable in KNX. --> enhancement 
Comment 12 Stefan Dirsch 2005-02-27 19:49:16 UTC
*** Bug 66784 has been marked as a duplicate of this bug. ***
Comment 13 Stephan Kulow 2006-03-08 16:08:33 UTC
I don't think there went any kind of work into knx since it's first introduction ;(

And I kind of don't see us doing it either.
Comment 14 Dirk Mueller 2006-05-04 13:13:12 UTC
also happens with standard nxclient, not only knx. reassign maintainer .

only happens after one suspend/resume cycle. a just freshly started session works fine. 
Comment 15 Stefan Dirsch 2006-05-04 14:27:52 UTC
So does a "setxkbmap de" help after the resume?
Comment 16 Dirk Mueller 2006-05-04 15:23:12 UTC
yes, it does help. 
Comment 17 Stefan Dirsch 2006-05-04 15:54:00 UTC
Ok. Stupid question. Are you doing the suspend/resume on the machine on which the nxlcient runs or on the machine, on which the Xsession runs? BTW, if you have any idea how to fix this issue, please let me know.
Comment 18 Dirk Mueller 2006-05-04 16:34:48 UTC
ah, thats not acpi / swsuspend suspend/resume I'm talking about but the NX suspend/resume. therefore, I'm doing this via nxclient (closing the window without ending the session running inside which then pops up a question where you can answer "Suspend"/"Terminate"/"Cancel"). 

I would assume that after resume the keyboard maps are no longer set correctly. NX does some fancy stuff via xrandr etc to adjust the NX session to the new display, perhaps there is a bug somewhere. the x keyboard mapping stuff is mostly black magic to me. 
Comment 19 Stefan Dirsch 2006-05-04 17:05:51 UTC
> ah, thats not acpi / swsuspend suspend/resume I'm talking about but the NX
> suspend/resume.
Good to know. :-) This means that NX suspend/resume somewhat works for you. It never did for me. Maybe Kurt can help here.
Comment 20 Stefan Dirsch 2007-05-11 07:57:52 UTC
JFYI.
Comment 21 Stefan Dirsch 2007-05-12 10:42:36 UTC
JFYI, Matthias. This is a bugreport, which is assigned to Egbert/me or with Egbert/me in CC or reported by Egbert/me.
Comment 22 Stefan Dirsch 2007-07-10 08:30:03 UTC
I can't reproduce this keyboard issue any longer. Check on the machine, on which the NX sessions runs, with "ps" that nxagent is started with the "-kbtype pc105/de" option or the keyboard geometry/layout, which you currently use on your regular Xserver. Even suspend/resume of the NX session works for me now.

Use the latest NX/FreeNX packages in our buildservice (project NX) + nxclient (3.0) from nomachine as NX client. knx no longer works. qtnx is still problematic.