Halton Huo wrote:
> Alan,
>
> On Thu, 2006-11-16 at 10:39 -0800, Alan Coopersmith wrote:
>> Halton Huo wrote:
>>> +gboolean
>>> +check_xsun_running()
>>> +{
>>> + GdkDisplay *display;
>>> + int min_keycodes, max_keycodes;
>>> +
>>> + /* determine Xsun is running */
>>> + display = gdk_display_get_default ();
>>> + XDisplayKeycodes ( GDK_DISPLAY_XDISPLAY (display), &min_keycodes,
>>> &max_keycodes);
>>> +
>>> + if ( max_keycodes == 254 )
>>> + return TRUE;
>>> + else
>>> + return FALSE;
>>> +}
>> So you can't run if the X server has a maximum keycode value of 254?
>> Really?
>> That's not what the bug said was causing vino to fail on Xsun.
>>
>> And if a change to the Xorg server causes it to report it can only map a
>> maximum
>> keycode of 254 instead of 255 vino should stop working? That doesn't make
>> any
>> sense.
> Yes I know, with debuging maximum keycode is a key difference between
> 254 and 255, it is better than verity the mapping table value, isn't it?
Why? I can easily change the Xsun maximum keycode to 255 - will that fix Vino?
(That's much easier than changing the Xsun keyboard code and every single one of
the 140 Xsun keytables shipped with Solaris and then reverifying each and
every
one of them, which is what would be required to make Xsun ape Xorg for the
sake
of one application who can't handle the standards-compliant keymapping tables
that Xsun returns.)
Will vino work with all X servers that report a maximum keycode of 255 no matter
what those keys are mapped to? Will it ever report that it can't work on an
X server that has a maximum keycode of 254 but otherwise has keymaps in the
style vino expects?
And why is this better than simply fixing Vino to work properly with valid
keymaps that simply aren't the style XFree86/Xorg exports? The code in libX11
to handle keymaps in the Xsun style is less than 10 lines long:
if ((per <= (col|1)) || (syms[col|1] == NoSymbol)) {
XConvertCase(syms[col&~1], &lsym, &usym);
if (!(col & 1))
return lsym;
else if (usym == lsym)
return NoSymbol;
else
return usym;
}
(You can see the full context in KeyBind.c in the libX11 source code - the
current upstream head for instance is at:
http://gitweb.freedesktop.org/?p=xorg/lib/libX11.git;a=blob;hb=HEAD;f=src/KeyBind.c
but this code has been in the upstream libX11 for years before vino was
written. The oldest copy I have unpacked at the moment is X11R6.1 from 1996,
which contains those lines exactly.)
>>> +available if you are using the X.org server.");
>> "Xorg server" - there is no "." in the program name. (It comes from the
>> X.Org Foundation, but the server is just "Xorg".)
> Already change it.
>> And what if the user is using an Xserver that's not Xsun or Xorg? X does
>> have this little-known feature called "remote display" that lets you display
>> a JDS desktop onto a Windows machine running Exceed or Cygwin/X, onto an
>> older
>> Linux box running XFree86, HP/DEC/IBM Unix's running their respective X
>> servers,
>> etc.
> This patch is internal only, we won't upstream it to community.
>
> Confusion on the feature called "remote display", is it the one
> Options->Remote Login->Enter Host Name... under cde-login? If so, I do
> not think it is related this patch.
That's how to remote display from another Solaris machine. I was thinking more
of a user sitting in front of a Windows machine running Cygwin, Exceed, or
X-Win32 and choosing their equivalent functionality to login to a Solaris JDS
session. Will this detect correctly whether or not vino can work in those
sessions?
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
