X2Go Bug report logs -
#674
keycode -> keycode translation harmful (makes configuration complex)
Reply or subscribe to this bug.
Toggle useless messages
Report forwarded
to x2go-dev@lists.x2go.org, X2Go Developers <x2go-dev@lists.x2go.org>
:
Bug#674
; Package x2goserver
.
(Fri, 14 Nov 2014 00:50:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Robert Siemer <Robert.Siemer@backsla.sh>
:
New Bug report received and forwarded. Copy sent to X2Go Developers <x2go-dev@lists.x2go.org>
.
(Fri, 14 Nov 2014 00:50:02 GMT) (full text, mbox, link).
Message #5 received at submit@bugs.x2go.org (full text, mbox, reply):
Package: x2goserver
Version: 4.0.1.18
This bug report is about keyboard configuration issues: it is very
challenging to have a custom keyboard configuration over x2go, while it
is running perfectly on the local machine.
With a Linux X2Go client the keyboard configuration could be entirely
transparent, like an ssh-session with X11-forwarding is. But it isn’t.
Background: In X11, the keycodes (numbers, e.g. 98) are sent by the
X11-keyboard driver to the X11-core. These numbers also get reported to
the applications. The applications in turn ask the X-server what they
should make out of those keycodes (e.g. 'a', called “symbols”).
The "final" problem I’m describing here is independent of the ‘keyboard
settings’ of the x2go client. Nevertheless I describe here only the
effects as seen with a configuration of "leave keyboard settings alone
and don’t do anything about it”.
With this kind of configuration the X-clients on the X2Go-server get the
same answer to for keycodes → symbols requests as they get local, but
they get it from the X2Go-server (nxagent or something). It seems that
these settings get copied over to the X2Go-server and are left alone. I
call those settings the “XKB configuration”.
A different X2Go-client keyboard configuration (e.g. auto), by the way,
would only reconfigure that XKB configuration, which can also be done by
hand with xkbcomp or setxkbmap.
—But the keycodes coming from the X2Go-client do not get sent over as
is. The are “mangled” or “translated” in between, especially on any
Linux client with evdev input device drivers.
There is no X11 way to reconfigure those keycodes, as they normally come
from the driver and are fixed for each key.
Three questions came to my mind:
1) Why are the keycodes translated?
2) What logic does this translation follow?
3) How can I influence it?
To the first question: it might be an artifact which is needed for other
platforms.
Second question: It turned out that the keycodes received by the
applications on the X2Go-server are exactly those that an old pre-evdev
Linux machine would generate. Those codes are written down and shipped
with Xorg (X-Server) in the file keycodes/xfree86. The file used these
days with the evdev driver is keycodes/evdev, where those known values
are recorded.
After changing my XKB configuration, completely “faking” a key on my
keyboard to be something else, the X2Go server (or nxagent or whatever)
still knew how to translate the keycode of it.
After some trial and error I found out that the translation instance
knowns about my original keyboard with the help of the some X property
on the root window:
$ xprop -root _XKB_RULES_NAMES
_XKB_RULES_NAMES(STRING) = "evdev", "pc104", "us", "altgr-intl", ""
The first string, here "evdev" dicts the rules file to use for XKB
configuration changes. Note: this X property is not part of the XKB
configuration, but setxkbmap read and records those five strings, which
guide XKB configuration composition so to say. (Those five strings are
rules, model, layout, variant and options, and they only guide which XKB
configuration pieces to load. Those pieces are named keycodes, types,
compat, symbols and geometry.)
I don’t know if X2Go actually reads and parses the rules file and the
XKB snippets or if the mappings are hardcoded, but changing the first
string in _XKB_RULES_NAMES (which dictates which rules file to use)
influences how the translation is done.
the following rules files dictate which keycodes to use:
evdev → evdev
xfree86 → xfree86
base → xfree86
When starting or resuming an X2Go session, the _XKB_RULES_NAMES property
is initially set to "xfree86", "null", "null", ... in the nxagent. It
really looks like that this X11 intermediary wants to fake “xfree86
hardware” (i.e. old PC hardware + kernel). As my current setup has no
“xfree86 settings” nowhere, I assume that this is fixed.
In effect: changing _XKB_RULES_NAMES to something where the rules is set
to “xfree86” or “base”, no translation takes place (or the translation
is 1:1). This has to be configured before X2Go session resume or
startup. Note that this does not change the XKB configuration (it would
only influence the next setxkbmap run).
Once no real keycode translation takes place, no XKB keyboard
(re-)configuration is necessary as the copied local setup is probably
exactly what you want.
Information forwarded
to x2go-dev@lists.x2go.org, X2Go Developers <x2go-dev@lists.x2go.org>
:
Bug#674
; Package x2goserver
.
(Fri, 14 Nov 2014 04:50:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.x2go.org>
.
(Fri, 14 Nov 2014 04:50:02 GMT) (full text, mbox, link).
Message #10 received at 674@bugs.x2go.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hi Robert,
On Fr 14 Nov 2014 01:39:31 CET, Robert Siemer wrote:
> Package: x2goserver
> Version: 4.0.1.18
>
> This bug report is about keyboard configuration issues: it is very
> challenging to have a custom keyboard configuration over x2go, while
> it is running perfectly on the local machine.
>
> With a Linux X2Go client the keyboard configuration could be
> entirely transparent, like an ssh-session with X11-forwarding is.
> But it isn’t.
>
> Background: In X11, the keycodes (numbers, e.g. 98) are sent by the
> X11-keyboard driver to the X11-core. These numbers also get reported
> to the applications. The applications in turn ask the X-server what
> they should make out of those keycodes (e.g. 'a', called “symbols”).
>
> The "final" problem I’m describing here is independent of the
> ‘keyboard settings’ of the x2go client. Nevertheless I describe here
> only the effects as seen with a configuration of "leave keyboard
> settings alone and don’t do anything about it”.
>
> With this kind of configuration the X-clients on the X2Go-server get
> the same answer to for keycodes → symbols requests as they get
> local, but they get it from the X2Go-server (nxagent or something).
> It seems that these settings get copied over to the X2Go-server and
> are left alone. I call those settings the “XKB configuration”.
>
> A different X2Go-client keyboard configuration (e.g. auto), by the
> way, would only reconfigure that XKB configuration, which can also
> be done by hand with xkbcomp or setxkbmap.
>
> —But the keycodes coming from the X2Go-client do not get sent over
> as is. The are “mangled” or “translated” in between, especially on
> any Linux client with evdev input device drivers.
>
> There is no X11 way to reconfigure those keycodes, as they normally
> come from the driver and are fixed for each key.
>
> Three questions came to my mind:
>
> 1) Why are the keycodes translated?
>
> 2) What logic does this translation follow?
>
> 3) How can I influence it?
>
>
> To the first question: it might be an artifact which is needed for
> other platforms.
>
> Second question: It turned out that the keycodes received by the
> applications on the X2Go-server are exactly those that an old
> pre-evdev Linux machine would generate. Those codes are written down
> and shipped with Xorg (X-Server) in the file keycodes/xfree86. The
> file used these days with the evdev driver is keycodes/evdev, where
> those known values are recorded.
>
> After changing my XKB configuration, completely “faking” a key on my
> keyboard to be something else, the X2Go server (or nxagent or
> whatever) still knew how to translate the keycode of it.
>
> After some trial and error I found out that the translation instance
> knowns about my original keyboard with the help of the some X
> property on the root window:
>
> $ xprop -root _XKB_RULES_NAMES
> _XKB_RULES_NAMES(STRING) = "evdev", "pc104", "us", "altgr-intl", ""
>
> The first string, here "evdev" dicts the rules file to use for XKB
> configuration changes. Note: this X property is not part of the XKB
> configuration, but setxkbmap read and records those five strings,
> which guide XKB configuration composition so to say. (Those five
> strings are rules, model, layout, variant and options, and they only
> guide which XKB configuration pieces to load. Those pieces are named
> keycodes, types, compat, symbols and geometry.)
>
> I don’t know if X2Go actually reads and parses the rules file and
> the XKB snippets or if the mappings are hardcoded, but changing the
> first string in _XKB_RULES_NAMES (which dictates which rules file to
> use) influences how the translation is done.
>
> the following rules files dictate which keycodes to use:
>
> evdev → evdev
> xfree86 → xfree86
> base → xfree86
>
> When starting or resuming an X2Go session, the _XKB_RULES_NAMES
> property is initially set to "xfree86", "null", "null", ... in the
> nxagent. It really looks like that this X11 intermediary wants to
> fake “xfree86 hardware” (i.e. old PC hardware + kernel). As my
> current setup has no “xfree86 settings” nowhere, I assume that this
> is fixed.
>
> In effect: changing _XKB_RULES_NAMES to something where the rules is
> set to “xfree86” or “base”, no translation takes place (or the
> translation is 1:1). This has to be configured before X2Go session
> resume or startup. Note that this does not change the XKB
> configuration (it would only influence the next setxkbmap run).
>
> Once no real keycode translation takes place, no XKB keyboard
> (re-)configuration is necessary as the copied local setup is
> probably exactly what you want.
I guess this is the best analysis on what happens in NX around
keyboard stuff, I have ever read. Thanks for that very good tutorial.
Now about fixing the bug.
I really think we should get evdev support into NX. What do you think?
But for now... so that I get a deeper feeling for this... Could you
provide a recipe for setting the correct / transparent keyboard setup
in the X2Go Session?
A sequence of commands on the client-side, a sequence of commands on
the server-side, something like that...
THANKS!
Mike
--
DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31
mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to x2go-dev@lists.x2go.org, X2Go Developers <x2go-dev@lists.x2go.org>
:
Bug#674
; Package x2goserver
.
(Fri, 14 Nov 2014 22:55:02 GMT) (full text, mbox, link).
Message #13 received at 674@bugs.x2go.org (full text, mbox, reply):
Am 14.11.2014 um 05:49 schrieb Mike Gabriel:
> I guess this is the best analysis on what happens in NX around
> keyboard stuff, I have ever read. Thanks for that very good tutorial.
That's what I was thinking when I read it, too ;-) But I'll have to read it again to fully get into it.
> Now about fixing the bug.
>
> I really think we should get evdev support into NX. What do you think?
>
> But for now... so that I get a deeper feeling for this... Could you
> provide a recipe for setting the correct / transparent keyboard setup
> in the X2Go Session?
>
> A sequence of commands on the client-side, a sequence of commands on
> the server-side, something like that...
Man setxkbmap states this:
-------
If you have an Xserver and a client shell running on different computers and XKB
configuration files on those machines are different you can get problems specifying a keyboard map
by model, layout, options
names. This is because setxkbcomp converts these names to names of XKB configuration
files according to files that are on the client side computer, then it sends the file names to the
server where the xkbcomp
has to compose a complete keyboard map using files which the server has. Thus if the sets
of files differ significantly the names that the setxkbmap generates can be unacceptable on the
server side. You can
solve this problem by running the xkbcomp on the client side too. With the -print option
setxkbmap just prints the file names in an appropriate format to its stdout and this output can be
piped directly to the
xkbcomp input. For example, the command
setxkbmap us -print | xkbcomp - $DISPLAY
makes both steps run on the same (client) machine and loads a keyboard map into the server.
-------
Wouldn't this bypass all this setxkbmap names and files altogether?
Uli
_______________________________________________
x2go-dev mailing list
x2go-dev@lists.x2go.org
http://lists.x2go.org/listinfo/x2go-dev
Information forwarded
to x2go-dev@lists.x2go.org, X2Go Developers <x2go-dev@lists.x2go.org>
:
Bug#674
; Package x2goserver
.
(Sun, 07 Dec 2014 04:20:01 GMT) (full text, mbox, link).
Acknowledgement sent
to Robert Siemer <Robert.Siemer@backsla.sh>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.x2go.org>
.
(Sun, 07 Dec 2014 04:20:02 GMT) (full text, mbox, link).
Message #18 received at 674@bugs.x2go.org (full text, mbox, reply):
> I really think we should get evdev support into NX. What do you think?
No, for keyboard configuration no special evdev support is needed.
> But for now... so that I get a deeper feeling for this... Could you
> provide a recipe for setting the correct / transparent keyboard
> setup in the X2Go Session?
For the commands see below. – At the moment I remove _XKB_RULES_NAMES
from the root window property before starting/resuming x2go.
> Wouldn't [running xkbcomp on the client] bypass all this setxkbmap
> names and files altogether?
I do already run xkbcomp on the client (and local as well) already, but
it has no influence on keycode translation. – I’m not sure why you
mentioned it...
I believe I know the reasoning behind this keycode translation: in a
heterogeneous environment, where you resume an x2go session from
different workstations, there exists only one way to represent the
different keyboards as an unchanging virtual keyboard. Yes: with keycode
translation.
The alternative would be to reconfigure XKB on each session resume,
which I believe is perfectly reasonable. – This is what I (would) do.
Allow me to draw a little ascii diagram here (look at it with fixed
width font):
local Xserver local Xclients x2go Xserv x2go Xclients
[1]
|==================xterm
|==================chromium
|==================xlsclients [3]
|==================setxkbmap
|==================xkbcomp [7]
| [2]
|------------------------------------|==============xterm
|------------------------------------|==============gnome-do [6]
|------------------------------------|==============xlsclients [4]
|------------------------------------|==============setxkbmap
|------------------------------------|==============xkbcomp [8]
This is about the X11 protocol level view of an x2go setup. There are
two Xservers running: the local one [1] and that x2go Xserver (that is
called nxagent?) [2]. Both are drawn as lines made of |
The x2go Xserver [2] represents its clients to the real local Xserver
[1] as X11 clients, but draws them in a different way (still X11
protocol, though).
An xlsclients [4] executed on the x2go server will be run against [2]
and show only the x2go Xclients. On the local Xserver [1] an execution
of xlsclients [3] lists all Xclients: the local ones and the remote ones.
Unfortunately the x2go Xserver [2] does not relay all and everything to
the local Xserver [1]. Examples: the X properties of the root window
(some kind of “global” storage for X clients) exist twice (in [1] and
[2]) and can differ. Also global hotkeys (“passive keygrabs”) of the
x2go Xclients will be stored in [2] and have no influence on [1]. The
launcher gnome-do [5] registers a hotkey: it will only be delivered to
[5] if the local Xserver [1] has no local Xclient waiting for it _and_
any of the x2go client windows is in focus. Otherwise [2] will not
even see the key event.
Back to XKB. As far as I could observe, the XKB setup consists of an XKB
configuration (which can be read and written with xkbcomp [7][8]) and
the root window property _XKB_RULES_NAMES (can be read with xprop and
setxkbmap and is written as a side effect of setxkbmap). Note that both
things exist twice, stored in [1] and [2].
Command line examples:
# dump current XKB configuration into one file
$ xkbcomp $DISPLAY full.xkb
# load full single-file XKB configuration
$ xkbcomp full.xkb $DISPLAY
# load from multiple files (xkbcomp will read more than one file):
# main keymap file triggers inclusion of files from system X11 files
$ xkbcomp keymap.xkb $DISPLAY
# example keymap.xkb file
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete+my" };
xkb_compat { include "complete" };
xkb_symbols { include "pc+inet(evdev)+eurosign(e)" };
xkb_geometry { include "pc(pc104)" };
};
# load from multiple files and have those searched for in your own tree
# otherwise they will be looked for in XKB root /usr/share/X11/xkb
$ xkbcomp -I/home/blabla/xkb mykeymap.xkb $DISPLAY
# read _XKB_RULES_NAMES
$ xprop -root _XKB_RULES_NAMES
_XKB_RULES_NAMES(STRING) = "evdev", "pc104", "us,us", "altgr-intl,",
"eurosign:e,caps:backspace,compose:rctrl"
# interpreted version of the above
$ setxkbmap -query
rules: evdev
model: pc104
layout: us,us
variant: altgr-intl,
options: eurosign:e,caps:backspace,compose:rctrl
# delete _XKB_RULES_NAMES property (and then read it)
$ xprop -root -remove _XKB_RULES_NAMES
$ xprop -root _XKB_RULES_NAMES
_XKB_RULES_NAMES: not found.
$ setxkbmap -query
Couldn't interpret _XKB_RULES_NAMES property
Use defaults: rules - 'base' model - 'pc105' layout - 'us'
rules: base
model: pc105
layout: us
# set _XKB_RULES_NAMES only(!)
# I wrote a tool for that (xprop can’t set STRING arrays)
# https://github.com/siemer/xproperty
$ ./xproperty.py _XKB_RULES_NAMES evdev pc104 us altgr-intl
<class 'Xlib.protocol.request.QueryExtension'>
_XKB_RULES_NAMES evdev pc104 us altgr-intl
# let setxkbmap read this property, override a part of it
# and ask which keymap it would load
$ setxkbmap -layout de -print
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwertz)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include "pc+de+inet(evdev)" };
xkb_geometry { include "pc(pc104)" };
};
# without “-print” setxkbmap will write the updated property _and_
# instruct the X11 server to load the resulting configuration
# with the help of xkbcomp
# → setxkbmap can’t just update the property alone
On x2go session startup, the x2go Xserver [2] does a superficial
investigation of what keyboard is used on the local Xserver [1] and sets
up an incomplete keycode translation to a keyboard known as “xfree86”.
It further creates an imperfect copy of the XKB configuration from [1]
to [2]. The _XKB_RULES_NAMES property on [2] is set to rules=xfree86,
model = pc???, layout = us(?) [I forgot the details].
Why is it a superficial investigation? – It takes the rules name from
_XKB_RULES_NAMES and deducts the resulting keycodes directly from that
(I believe). Even though in a common setup rules name “evdev” results in
one specific set of keycodes and rules name “xfree86” in another
specific set of keycodes, this is not a must.
Why is the keycode translation incomplete? – As far as I observed it,
“unusual” or unknown keycodes are not translated and passed as-is.
Why is the XKB configuration copy imperfect? – I did a XKB dump on the
local Xserver [1] and the x2go Xserver [2] after starting a new session.
Keys with four levels of symbols turned into two-level-keysyms. –
_Loading_ (i.e. xkbcomp/setxkbmap) a four-level configuration is no
problem, though.
Note: the imperfect copy of the XKB configuration is almost always
useless, because the copied configuration does not match the new
(translated) keycodes!
Resuming an x2go session triggers the same superficial keyboard
investigation, the translation kicks in again, but the XKB configuration
is not touched (i.e. is not copied from [1] to [2]).
Deleting the _XKB_RULES_NAMES property before session startup/resume or
setting the first part (that is the “rules” part) to some unknown string
results in untranslated keycodes.
Please pardon me for repeating myself in some instances.
Robert
Information forwarded
to x2go-dev@lists.x2go.org, X2Go Developers <x2go-dev@lists.x2go.org>
:
Bug#674
; Package x2goserver
.
(Sun, 07 Dec 2014 23:10:01 GMT) (full text, mbox, link).
Acknowledgement sent
to uli42@gmx.de
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.x2go.org>
.
(Sun, 07 Dec 2014 23:10:01 GMT) (full text, mbox, link).
Message #23 received at 674@bugs.x2go.org (full text, mbox, reply):
On Sun, Dec 7, 2014 at 5:07 AM, Robert Siemer <Robert.Siemer@backsla.sh> wrote:
> On x2go session startup, the x2go Xserver [2] does a superficial
> investigation of what keyboard is used on the local Xserver [1] and sets up
> an incomplete keycode translation to a keyboard known as “xfree86”. It
> further creates an imperfect copy of the XKB configuration from [1] to [2].
> The _XKB_RULES_NAMES property on [2] is set to rules=xfree86, model = pc???,
> layout = us(?) [I forgot the details].
>
> Why is it a superficial investigation? – It takes the rules name from
> _XKB_RULES_NAMES and deducts the resulting keycodes directly from that (I
> believe). Even though in a common setup rules name “evdev” results in one
> specific set of keycodes and rules name “xfree86” in another specific set of
> keycodes, this is not a must.
>
> Why is the keycode translation incomplete? – As far as I observed it,
> “unusual” or unknown keycodes are not translated and passed as-is.
>
> Why is the XKB configuration copy imperfect? – I did a XKB dump on the local
> Xserver [1] and the x2go Xserver [2] after starting a new session. Keys with
> four levels of symbols turned into two-level-keysyms. – _Loading_ (i.e.
> xkbcomp/setxkbmap) a four-level configuration is no problem, though.
>
> Note: the imperfect copy of the XKB configuration is almost always useless,
> because the copied configuration does not match the new (translated)
> keycodes!
>
> Resuming an x2go session triggers the same superficial keyboard
> investigation, the translation kicks in again, but the XKB configuration is
> not touched (i.e. is not copied from [1] to [2]).
>
> Deleting the _XKB_RULES_NAMES property before session startup/resume or
> setting the first part (that is the “rules” part) to some unknown string
> results in untranslated keycodes.
I am not sure if I am getting this right. Will using xkbcomp on the
local server, pushing the result to the nxagent and loading it there
result in a clean keyboard setup or not? Do we need to disable setting
up the translation within the nx code to make that work?
Uli
BTW: You can find the code for the keycode translation in
nx-x11/programs/Xserver/hw/nxagent/Keyboard.c. It seems some kind of
translation from evdev to pc105 is done. You can also see that if
there is no "xfree86" rules file the one called "xorg" is used instead
(if available, of course).
Information forwarded
to x2go-dev@lists.x2go.org, X2Go Developers <x2go-dev@lists.x2go.org>
:
Bug#674
; Package x2goserver
.
(Sat, 13 Dec 2014 00:50:01 GMT) (full text, mbox, link).
Acknowledgement sent
to Robert Siemer <Robert.Siemer@backsla.sh>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.x2go.org>
.
(Sat, 13 Dec 2014 00:50:02 GMT) (full text, mbox, link).
Message #28 received at 674@bugs.x2go.org (full text, mbox, reply):
On 08/12/14 00:07, Ulrich Sibiller wrote:
> On Sun, Dec 7, 2014 at 5:07 AM, Robert Siemer <Robert.Siemer@backsla.sh> wrote:
>> On x2go session startup, the x2go Xserver [2] does a superficial
>> investigation of what keyboard is used on the local Xserver [1] and sets up
>> an incomplete keycode translation to a keyboard known as “xfree86”. It
>> further creates an imperfect copy of the XKB configuration from [1] to [2].
>> The _XKB_RULES_NAMES property on [2] is set to rules=xfree86, model = pc???,
>> layout = us(?) [I forgot the details].
>>
>> Why is it a superficial investigation? – It takes the rules name from
>> _XKB_RULES_NAMES and deducts the resulting keycodes directly from that (I
>> believe). Even though in a common setup rules name “evdev” results in one
>> specific set of keycodes and rules name “xfree86” in another specific set of
>> keycodes, this is not a must.
>>
>> Why is the keycode translation incomplete? – As far as I observed it,
>> “unusual” or unknown keycodes are not translated and passed as-is.
>>
>> Why is the XKB configuration copy imperfect? – I did a XKB dump on the local
>> Xserver [1] and the x2go Xserver [2] after starting a new session. Keys with
>> four levels of symbols turned into two-level-keysyms. – _Loading_ (i.e.
>> xkbcomp/setxkbmap) a four-level configuration is no problem, though.
>>
>> Note: the imperfect copy of the XKB configuration is almost always useless,
>> because the copied configuration does not match the new (translated)
>> keycodes!
>>
>> Resuming an x2go session triggers the same superficial keyboard
>> investigation, the translation kicks in again, but the XKB configuration is
>> not touched (i.e. is not copied from [1] to [2]).
>>
>> Deleting the _XKB_RULES_NAMES property before session startup/resume or
>> setting the first part (that is the “rules” part) to some unknown string
>> results in untranslated keycodes.
>
> I am not sure if I am getting this right. Will using xkbcomp on the
> local server, pushing the result to the nxagent and loading it there
> result in a clean keyboard setup or not?
That depends on whether the keycode translation is on or off.
If the translation it is not in effect, then yes, you get a setup like
you have without x2go.
If the translation is on, you get a skewed setup.
Note that the x2go (with the setting of “do nothing”) does a non-perfect
copy with the same effect: if the translation is effective, the keyboard
is skewed and you are force to load at least “something” to fix XKB. If
the translation is off, you “only” need to load XKB configuration if
that non-perfect copy annoys you...
Btw, the forme is exactly what I do: dump local XKB configuration, make
sure I don’t get a translation in x2go and load it on the other side.
> BTW: You can find the code for the keycode translation in
> nx-x11/programs/Xserver/hw/nxagent/Keyboard.c.
Thanks for the pointer! I had a look at it. As I suspected: the
translation is “bad”. Sometimes two different keycodes are translated to
the same keycode. How are you supposed to tell them apart on the remote
side? You can’t.
> It seems some kind of translation from evdev to pc105 is done.
The naming is a little funny: the keycodes generated by the kernel
before evdev were not called like that, were they?
> Do we need to disable setting
> up the translation within the nx code to make that work?
That would be great as a first step.
Information forwarded
to x2go-dev@lists.x2go.org, X2Go Developers <x2go-dev@lists.x2go.org>
:
Bug#674
; Package x2goserver
.
(Tue, 16 Dec 2014 09:45:01 GMT) (full text, mbox, link).
Acknowledgement sent
to Ulrich Sibiller <uli42@gmx.de>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.x2go.org>
.
(Tue, 16 Dec 2014 09:45:02 GMT) (full text, mbox, link).
Message #33 received at 674@bugs.x2go.org (full text, mbox, reply):
On Sat, Dec 13, 2014 at 1:45 AM, Robert Siemer <Robert.Siemer@backsla.sh> wrote:
> If the translation is on, you get a skewed setup.
>
> Note that the x2go (with the setting of “do nothing”) does a non-perfect
> copy with the same effect: if the translation is effective, the keyboard is
> skewed and you are force to load at least “something” to fix XKB. If the
> translation is off, you “only” need to load XKB configuration if that
> non-perfect copy annoys you...
> Thanks for the pointer! I had a look at it. As I suspected: the translation
> is “bad”. Sometimes two different keycodes are translated to the same
> keycode. How are you supposed to tell them apart on the remote side? You
> can’t.
>
>> It seems some kind of translation from evdev to pc105 is done.
>
> The naming is a little funny: the keycodes generated by the kernel before
> evdev were not called like that, were they?
I don't think so.
>> Do we need to disable setting
>> up the translation within the nx code to make that work?
>
> That would be great as a first step.
I was wondering why this translations had been introduced. It emerged
between nxagent 3.2.0-10 and 3.3.0-9. The changelog between these
releases contains (among others) these changes:
nxagent-3.3.0-9
- Changed Keyboard initialization and reset. This change should fix
TR11F02129, TR11F02131, TR11F02132.
nxagent-3.3.0-4
- Fix the XKB map load in the case of 64 bit server.
nxagent-3.3.0-3
- Fixed TR10F02119. If the remote X display is using evdev keyboard
then copy maps from remote.
nxagent-3.2.0-12
- Fixed TR08E01814. Added shadow keymap initialization in order to
enable nxcompshad to translate keycodes across different layouts.
So it MIGHT have been introduced mainly for shadow sessions. The
TR10F02119 refers to Ubuntu 8.10, which - according to some other
posts I found - is the version that introduced evdev. So the fix that
solved evdev problems is causing problems when evdev is enabled.
I also looked at the source and found that clearing the property seems
to be the only way to disable the translation. (apart from disabling
XKB completely).
Uli
Information forwarded
to x2go-dev@lists.x2go.org, X2Go Developers <x2go-dev@lists.x2go.org>
:
Bug#674
; Package x2goserver
.
(Tue, 16 Dec 2014 14:45:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.x2go.org>
.
(Tue, 16 Dec 2014 14:45:02 GMT) (full text, mbox, link).
Message #38 received at 674@bugs.x2go.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hi Ulrich,
On Di 16 Dez 2014 10:40:06 CET, Ulrich Sibiller wrote:
> On Sat, Dec 13, 2014 at 1:45 AM, Robert Siemer
> <Robert.Siemer@backsla.sh> wrote:
>
>> If the translation is on, you get a skewed setup.
>>
>> Note that the x2go (with the setting of “do nothing”) does a non-perfect
>> copy with the same effect: if the translation is effective, the keyboard is
>> skewed and you are force to load at least “something” to fix XKB. If the
>> translation is off, you “only” need to load XKB configuration if that
>> non-perfect copy annoys you...
>
>> Thanks for the pointer! I had a look at it. As I suspected: the translation
>> is “bad”. Sometimes two different keycodes are translated to the same
>> keycode. How are you supposed to tell them apart on the remote side? You
>> can’t.
>>
>>> It seems some kind of translation from evdev to pc105 is done.
>>
>> The naming is a little funny: the keycodes generated by the kernel before
>> evdev were not called like that, were they?
>
> I don't think so.
>
>>> Do we need to disable setting
>>> up the translation within the nx code to make that work?
>>
>> That would be great as a first step.
>
> I was wondering why this translations had been introduced. It emerged
> between nxagent 3.2.0-10 and 3.3.0-9. The changelog between these
> releases contains (among others) these changes:
>
> nxagent-3.3.0-9
>
> - Changed Keyboard initialization and reset. This change should fix
> TR11F02129, TR11F02131, TR11F02132.
>
> nxagent-3.3.0-4
>
> - Fix the XKB map load in the case of 64 bit server.
>
> nxagent-3.3.0-3
>
> - Fixed TR10F02119. If the remote X display is using evdev keyboard
> then copy maps from remote.
>
> nxagent-3.2.0-12
>
> - Fixed TR08E01814. Added shadow keymap initialization in order to
> enable nxcompshad to translate keycodes across different layouts.
>
> So it MIGHT have been introduced mainly for shadow sessions. The
> TR10F02119 refers to Ubuntu 8.10, which - according to some other
> posts I found - is the version that introduced evdev. So the fix that
> solved evdev problems is causing problems when evdev is enabled.
>
> I also looked at the source and found that clearing the property seems
> to be the only way to disable the translation. (apart from disabling
> XKB completely).
>
> Uli
Note that you can view the changes between versions of nxagent via
nx-libs.git [1].
Use the "commitdiff" links in the right column...
Mike
[1] http://code.x2go.org/gitweb?p=nx-libs.git;a=shortlog;h=refs/heads/nxagent
--
DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31
mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to x2go-dev@lists.x2go.org, X2Go Developers <x2go-dev@lists.x2go.org>
:
Bug#674
; Package x2goserver
.
(Sat, 03 Dec 2016 01:25:01 GMT) (full text, mbox, link).
Acknowledgement sent
to "FedEx 2Day A.M." <john.byers@protechaid.us>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.x2go.org>
.
(Sat, 03 Dec 2016 01:25:02 GMT) (full text, mbox, link).
Message #43 received at 674@bugs.x2go.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Dear Customer,
Your parcel has arrived at November 29. Courier was unable to deliver the parcel to you.
Delivery Label is attached to this email.
Yours trully,
John Byers,
Operation Agent.
[Delivery_Notification_0000566462.zip (application/zip, attachment)]
Information forwarded
to x2go-dev@lists.x2go.org, X2Go Developers <x2go-dev@lists.x2go.org>
:
Bug#674
; Package x2goserver
.
(Mon, 19 Dec 2016 00:00:02 GMT) (full text, mbox, link).
Acknowledgement sent
to "FedEx Priority Delivery" <tim.brewer@g70.com.br>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.x2go.org>
.
(Mon, 19 Dec 2016 00:00:03 GMT) (full text, mbox, link).
Message #48 received at 674@bugs.x2go.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Dear Customer,
This is to confirm that your item has been shipped at December 17.
You can find more details in this e-mail attachment!
Yours respectfully,
Tim Brewer,
Parcels Delivery Manager.
[Delivery-Receipt-00860423.zip (application/zip, attachment)]
Information forwarded
to x2go-dev@lists.x2go.org, X2Go Developers <x2go-dev@lists.x2go.org>
:
Bug#674
; Package x2goserver
.
(Mon, 26 Dec 2016 02:00:01 GMT) (full text, mbox, link).
Acknowledgement sent
to "FedEx Ground Support" <ryan.ford@jotisautomobile.com>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.x2go.org>
.
(Mon, 26 Dec 2016 02:00:02 GMT) (full text, mbox, link).
Message #53 received at 674@bugs.x2go.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Dear Customer,
We can not deliver your parcel arrived at December 23.
Please review delivery label in attachment!
Thank you for your consideration,
Ryan Ford,
Delivery Clerk.
[Delivery-Details-00000745951.zip (application/zip, attachment)]
Information forwarded
to x2go-dev@lists.x2go.org, X2Go Developers <x2go-dev@lists.x2go.org>
:
Bug#674
; Package x2goserver
.
(Sat, 01 Jul 2017 06:00:03 GMT) (full text, mbox, link).
Acknowledgement sent
to eaplicat@eua12.servidoreua12.srv.br
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.x2go.org>
.
(Sat, 01 Jul 2017 06:00:04 GMT) (full text, mbox, link).
Message #58 received at 674@bugs.x2go.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Dear Customer,
UPS courier was unable to contact you for your parcel delivery.
Download postal receipt attached to e-mail!
Thanks,
,
UPS Mail Delivery Clerk.
[UPS-Label-009455102.zip (application/zip, attachment)]
Information forwarded
to x2go-dev@lists.x2go.org, X2Go Developers <x2go-dev@lists.x2go.org>
:
Bug#674
; Package x2goserver
.
(Wed, 05 Jul 2017 09:15:02 GMT) (full text, mbox, link).
Acknowledgement sent
to evolve@veam.websitewelcome.com
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.x2go.org>
.
(Wed, 05 Jul 2017 09:15:02 GMT) (full text, mbox, link).
Message #63 received at 674@bugs.x2go.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Dear Customer,
This is to confirm that your item has been shipped at July 04.
Download postal receipt attached to e-mail!
With sincere appreciation,
,
UPS Support Agent.
[UPS-Delivery-Details-5539783.zip (application/zip, attachment)]
Information forwarded
to x2go-dev@lists.x2go.org, X2Go Developers <x2go-dev@lists.x2go.org>
:
Bug#674
; Package x2goserver
.
(Thu, 06 Jul 2017 05:55:01 GMT) (full text, mbox, link).
Acknowledgement sent
to thepesc7@box1055.bluehost.com
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.x2go.org>
.
(Thu, 06 Jul 2017 05:55:02 GMT) (full text, mbox, link).
Message #68 received at 674@bugs.x2go.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Dear Customer,
We can not deliver your parcel arrived at July 05.
You can find more details in this e-mail attachment!
Many thanks,
,
UPS Senior Office Manager.
[UPS-Receipt-05580358.zip (application/zip, attachment)]
Information forwarded
to x2go-dev@lists.x2go.org, X2Go Developers <x2go-dev@lists.x2go.org>
:
Bug#674
; Package x2goserver
.
(Sun, 12 Sep 2021 01:20:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Janeth Utuah <utj501829@gmail.com>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.x2go.org>
.
(Sun, 12 Sep 2021 01:20:02 GMT) (full text, mbox, link).
Message #73 received at 674@bugs.x2go.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Schöne Grüße!!
Ich bin Janeth Utuah.
Ich brauche Ihre Unterstützung, um in Ihr Land zu ziehen,
damit ich investieren und meine Ausbildung fortsetzen kann.
Freundliche Grüße,
Janeth.
[Message part 2 (text/html, inline)]
Information forwarded
to x2go-dev@lists.x2go.org, X2Go Developers <x2go-dev@lists.x2go.org>
:
Bug#674
; Package x2goserver
.
(Thu, 23 Sep 2021 16:05:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Janeth Utuah <utj501829@gmail.com>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.x2go.org>
.
(Thu, 23 Sep 2021 16:05:03 GMT) (full text, mbox, link).
Message #78 received at 674@bugs.x2go.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Schöne Grüße!!
Ich bin Janeth Utuah.
Ich brauche Ihre Unterstützung, um in Ihr Land zu ziehen,
damit ich investieren und meine Ausbildung fortsetzen kann.
Freundliche Grüße,
Janeth.
[Message part 2 (text/html, inline)]
Send a report that this bug log contains spam.
X2Go Developers <owner@bugs.x2go.org>.
Last modified:
Sat Apr 1 01:05:59 2023;
Machine Name:
ymir.das-netzwerkteam.de
X2Go Bug tracking system
Debbugs is free software and licensed under the terms of the GNU
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.
Copyright © 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson,
2005-2017 Don Armstrong, and many other contributors.