Le lundi 04 octobre 2010 à 15:26 +0200, Julien Cristau a écrit : > > * 11_no_xhost_thanks.patch: new patch. Drops the very suspicious xhost > > authentication that is set in the login window. In addition to > > questioning the security, it interacts badly with the Xephyr patch. > > How does this interact with environments which change the hostname based > on dhcp? Badly, of course. Such environments are the reason why this code was introduced upstream. If someone familiar with X authentication code can assure me that it is safe, I can rework the 11_xephyr_nested.patch so that it can work together with it. However, gdm3 is the only display manager to do that. Without this code, you have to handle hostname changes just like with other display managers, as documented in many places. (It’s a matter of calling xhost add with the new hostname.) In all cases, I strongly disagree with the way upstream chose to work around the problem of hostname changes. If it has to be handled, it should be done with a hook in /etc/network/if-up.d instead. > > + Rework the xkb setting in the Init script. Passing model/layout/ > > variant/options seems to work better than keymap/types/compat/… > > That script makes me cringe. If your goal is to have the same keymap in > the nested server as in the host, then run 'xkbcomp $GDM_PARENT_DISPLAY > $NEW_DISPLAY'? xkbcomp was my first attempt when I noticed the upstream script didn’t work anymore. However it made either xkbcomp or the Xephyr process crash, depending on the invocation, so I gave up and tried several approaches, retaining the only one that worked. (I have no idea why the others don’t.) The help of X gurus would be appreciated, but I understand they are busy reviewing gigantic patches that inconsiderate people drop in their face :) Cheers, -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `- […] I will see what I can do for you.” -- Jörg Schilling
Attachment:
signature.asc
Description: This is a digitally signed message part