Hi,
I wanted to ask what you know about locating RDP servers on a network, I saw
no such functionality is included in rdesktop. Would it be possible to locate
RDP servers via SLP?
Also I made some little patches to rdp.c and proto.h which allow C++ projects
to link and access the rdesktop functions. I will post it on the Patches
forum at the SourceForge page.
Greets,
Arend jr.
--
Arend van Beelen jr.
http://www.liacs.nl/~dvbeelen/
"I love you, I'll kill you, but I'll love you forever."
- Enigma

Yesterday, I found out that the developer of krdc had split up his class to
create a VNC connection into a base a class and a VNC specific class, this
way I would be able to easily write a RDP specific class so that krdc will
'natively speak' the RDP protocol. After playing a little with it, I think I
will take this approach and take some of the rdesktop source in order to
build the RDP class. I will try to keep to the rdesktop source intact as much
as possible so that any integration of new rdesktop features or bugfixes will
be as easy as possible.
I'll keep in touch as my work proceeds.
Greets,
Arend jr.
--
Arend van Beelen jr.
http://www.liacs.nl/~dvbeelen/
"My name is Lucifer, please take my hand."
- Black Sabbath

On Thu, 2002-12-26 at 13:18, Arend van Beelen jr. wrote:
> > I don't think libraries should draw "their own thing" to the screen, to
> > a tty, or communicate with the user at all. That's the job of an
> > application. While I'd grant exceptions to this rule, this certainly
> > doesn't seem like one of them.
>
> > rdesktop shouldn't have/need any BSD socket code in the "back end". All
> > it should have is the glue needed to interface with the X11 server. It
> > should communicate over file descriptors to a parent process which has
> > already set up the network connect (possibly asynchronously, and
> > possibly providing feedback to the user). rdesktop should certainly
> > include one of these such programs, but I think that I should be able to
> > build my own simple front-end as easily as a shell script:
>
> > #!/bin/sh
> > exec xalf tcpserver $1 3389 rdesktop-x11 ${1+$@}
> Okay, I agree. But then I would like to ask: Would it be possible that the
> frontend provides the window in which the back-end can draw?
You're using too global of terms. "back end" and "front end" don't mean
anything useful, and are often a source of confusion (as they are here).
The x11 display driver in rdesktop's source should examine an
environment variable (X11WINDOWID or something similar) - this would
certainly be a very X11-specific mechanism, but since some operating
systems don't allow (BeOS), or don't make it easy (Win32) to draw in
another applications' window, you may have to read on:
> I still think return values are more easy here, it allows krdc to map error
> strings to error codes, with one string for unknown error codes. No matter
> how you do it, krdc needs modification after new error codes are introduced
> since the i18n translations of the error strings need to be updated.
No it doesn't. Ideally, rdesktop should be internationalized.
> Something different, though, the author of krdc advises me to port rdesktop to
> a Qt based class which can be included in the application. As a few
> guidelines he told me the following things had to be done to accomplish that:
> - the rdesktop loop must run in its own thread
> - rdesktop must not poll, but instead get events from the Qt loop (for VNC I
> do this using a few queues for the various event types, that are protected by
> a mutex)
> - rdesktop must call KApplication::lock() before drawing (it can still draw
> itself, but krdc provides the Window)
> This, of course, would provide the best possible integration for krdc and krdc
> would become independent of rdesktop, a good point. But from the other side,
> it would mean that any goodies rdesktop might bring in the future need to be
> reimplemented by hand in the krdc tree.
I think it would be fine to make a Qt display driver. Threading is not
your issue here. However the networking code would require abstraction.
This would be easier with the changes to rdesktop that I suggested.
However, in that case, you would need to spawn a separate copy of
rdesktop-qt for each window you're going to draw onto.
I'm not familiar enough with Qt to provide sane advice here, but one of
two things is happening. Either Qt will poll() the file descriptors for
the network, or rdesktop poll()'s Qt's file descriptors. If Qt does it,
then ui_select() (as provided) will be enough. Simply pass the
rdp_socket to the Qt subsystem and you're done. If rdesktop does it,
then use the model used by xwin.c and you're fine.
If the backend is _not_ a library, then a complex IPC will be needed to
pass the QtWindow (whatever) objects around. This IMO, is a shortcoming
of Qt, and may necessitate a tighter integration (and thus, more
potential for bugs, blah)

> I don't think libraries should draw "their own thing" to the screen, to
> a tty, or communicate with the user at all. That's the job of an
> application. While I'd grant exceptions to this rule, this certainly
> doesn't seem like one of them.
> rdesktop shouldn't have/need any BSD socket code in the "back end". All
> it should have is the glue needed to interface with the X11 server. It
> should communicate over file descriptors to a parent process which has
> already set up the network connect (possibly asynchronously, and
> possibly providing feedback to the user). rdesktop should certainly
> include one of these such programs, but I think that I should be able to
> build my own simple front-end as easily as a shell script:
> #!/bin/sh
> exec xalf tcpserver $1 3389 rdesktop-x11 ${1+$@}
Okay, I agree. But then I would like to ask: Would it be possible that the
frontend provides the window in which the back-end can draw?
> I also think using exit-codes to describe problems is normally a good
> idea, but perhaps sending machine-parsable error strings to standard
> error is a better way to do it. that way if rdesktop changes, or needs a
> new error, krdc doesn't need rewrites:
> Zdisplay problem: human readable part here
> Wwarning problem: human readable part here
> etc. It's easy for programs to parse, but if a human happens to be
> there, it's okay. The best part is, you no longer depend on bsdish
> semantics for signals (e.g., you can safely ignore SIGCHLD)
> Specify the first character as what kind of message this is:
> Z fatal error
> W warning; let the user know
> M model warning: interrupt their session
> X informational; display in status bar(?)
> etc.
I still think return values are more easy here, it allows krdc to map error
strings to error codes, with one string for unknown error codes. No matter
how you do it, krdc needs modification after new error codes are introduced
since the i18n translations of the error strings need to be updated.
Something different, though, the author of krdc advises me to port rdesktop to
a Qt based class which can be included in the application. As a few
guidelines he told me the following things had to be done to accomplish that:
- the rdesktop loop must run in its own thread
- rdesktop must not poll, but instead get events from the Qt loop (for VNC I
do this using a few queues for the various event types, that are protected by
a mutex)
- rdesktop must call KApplication::lock() before drawing (it can still draw
itself, but krdc provides the Window)
This, of course, would provide the best possible integration for krdc and krdc
would become independent of rdesktop, a good point. But from the other side,
it would mean that any goodies rdesktop might bring in the future need to be
reimplemented by hand in the krdc tree.
--
Arend van Beelen jr.
http://www.liacs.nl/~dvbeelen/
"Thus saith the Lord, the King of Israel and his redeemer, the Lord of hosts,
I am the first, and I am the last, and beside Me there is no god."
- Isaiah 44:6

On Tue, 2002-12-24 at 05:52, Arend van Beelen jr. wrote:
> Op woensdag 25 december 2002 01:14, schreef u:
> > Alternatively: rdesktop could be split into two components; a front-end
> > (shell script) and the backend-code that would rely on tcpclient (or an
> > alternative front end). That way, feedback itself could be provided by
> > the shell script in a system-defined way (outside of rdesktop core).
> Personally, I would prefer the approach of splitting rdesktop into two parts,
> the back-end, which could be a library (librdp?), and the front-end would be
> the console app. This way, I can use the library directly from krdc and
> bypass the console app (this would also resolve the problem of more detailed
> return values). I think we can come quite far if we just let rdesktop.c/h be
> the front-end and put the external functions in the library.
> What are your ideas about this?
I don't think libraries should draw "their own thing" to the screen, to
a tty, or communicate with the user at all. That's the job of an
application. While I'd grant exceptions to this rule, this certainly
doesn't seem like one of them.
rdesktop shouldn't have/need any BSD socket code in the "back end". All
it should have is the glue needed to interface with the X11 server. It
should communicate over file descriptors to a parent process which has
already set up the network connect (possibly asynchronously, and
possibly providing feedback to the user). rdesktop should certainly
include one of these such programs, but I think that I should be able to
build my own simple front-end as easily as a shell script:
#!/bin/sh
exec xalf tcpserver $1 3389 rdesktop-x11 ${1+$@}
I also think using exit-codes to describe problems is normally a good
idea, but perhaps sending machine-parsable error strings to standard
error is a better way to do it. that way if rdesktop changes, or needs a
new error, krdc doesn't need rewrites:
Zdisplay problem: human readable part here
Wwarning problem: human readable part here
etc. It's easy for programs to parse, but if a human happens to be
there, it's okay. The best part is, you no longer depend on bsdish
semantics for signals (e.g., you can safely ignore SIGCHLD)
Specify the first character as what kind of message this is:
Z fatal error
W warning; let the user know
M model warning: interrupt their session
X informational; display in status bar(?)
etc.
I think people forget that the reason we all like unixish systems is
because IPC makes our jobs so much easier. Building pipelines is what
makes the unix-user experience so powerful. You build programs like krdc
and the rdesktop shell script for "most of the time". You fix rdesktop
in the way I suggest for the next problem you run across.
I am not without active critique; using libraries as you suggest will
cause you problems down the road. krdc will have to be updated every
time rdesktop changes, or that API changes. the API will likely be
largely altered when RDP5 support becomes available (if... :), or if we
wanted a different event model (such as I'm discussing right now) for
porting to a system with an event model different than what X11 uses
(e.g. Win32's Winsock2, BeOS's MPI, or an embedded system!) and wanted
to keep those changes in sync with the real rdesktop cvs, then krdc and
all other front-ends need changing again.
By being more like existing unix applications (as I suggest), we're
bypassing those problems higher up. I mean, there _is_ a reason unixish
systems work they way that do :)

Hello all,
I have posted this question to the rdesktop-users mailing list, but with
little success. So i am trying here, maybe someone will be able to solve
my problem...
igor
-- snip --
I do not seem to be able to use rdesktop to connect to to windows XP
computers.
I am running debian sid and tried the 1.1.0+cvs20020907-1 version of the
debian package and also tried to use the 1.2beta1 from sf.net.
It compiles just fine, but when i am trying to connect i get following:
aragorn:~% rdesktop borknagar
rdesktop: A Remote Desktop Protocol client.
Version 1.1.0+cvs20020907. Copyright (C) 1999-2001 Matt Chapman.
See http://www.rdesktop.org/ for more information.
Connection successful.
Disconnecting...
I get the window with the blue background pop up, but right where it
supposed to give me the login prompt the window closes and i am back at
the shell prompt.
Same with 1.2beta1, but i get no output at all. it just drops me back to
the prompt.
I also tried from RedHat 8 machine connecting to the identical XP
machine,
but result is the same. What gives ?
Also, from what i can see, there are absolutely no settings for the XP
terminal services. Does anyone know what is going on ?
-- snip --
--
Uptime : 46 days, 19:04

Op woensdag 25 december 2002 01:14, schreef u:
> Alternatively: rdesktop could be split into two components; a front-end
> (shell script) and the backend-code that would rely on tcpclient (or an
> alternative front end). That way, feedback itself could be provided by
> the shell script in a system-defined way (outside of rdesktop core).
Personally, I would prefer the approach of splitting rdesktop into two parts,
the back-end, which could be a library (librdp?), and the front-end would be
the console app. This way, I can use the library directly from krdc and
bypass the console app (this would also resolve the problem of more detailed
return values). I think we can come quite far if we just let rdesktop.c/h be
the front-end and put the external functions in the library.
What are your ideas about this?
Greets,
Arend jr.
--
Arend van Beelen jr.
http://www.liacs.nl/~dvbeelen/
"My advise is, if you maintain this lifestyle, you won't reach 30."
- Marillion

On Mon, 2002-12-23 at 10:33, Arend van Beelen jr. wrote:
> Also I found that when the connection can't be established because the network
> is not reachable, rdesktop will wait very long till it responds. When you
> click the window away, one would expect the program to terminate, but still
> it keeps waiting - this is very confusing. Is it possible to terminate the
> entire program when the window is closed?
This isn't all that difficult for X11 systems; using non-blocking
connects <URL:http://cr.yp.to/docs/connect.html&gt; - but if rDesktop were
ported to a system that didn't have an analogous for ConnectionNumber(),
you'd need threads, or possibly some reordering of the
display-abstraction code and startup.
This raises an interesting question: If we bring the RDP connection up
before the X11 connection, then there's no feedback to the user that
rdesktop actually started (if the RDP connection hangs, etc). On the
other hand, how is this solved if we wanted to port rdesktop (cleanly)
to a system with a screwed up event model (Win32) or one without an
event model at all (some embedded systems)?
Do we have the xwin.c provide a ui_poll_handle() function? Or do we find
another way to provide feedback.
Alternatively: rdesktop could be split into two components; a front-end
(shell script) and the backend-code that would rely on tcpclient (or an
alternative front end). That way, feedback itself could be provided by
the shell script in a system-defined way (outside of rdesktop core).

I'm using krdc (KDE Remote Desktop Connection) to provide a KDE frontend for
rdesktop. I wanted to use the return values of rdesktop so in case of failure
krdc can give a useful error to the user, but I found out rdesktop simply
returns 0 or 1. Would it be possible to set up a list with return values and
their meaning so frontends can better determine what went wrond?
For instance:
0: succes
1: incorrect arguments
2: network unreachable
3: connection refused
4: time-out
5: incorrect username or password
6: ...
Also I found that when the connection can't be established because the network
is not reachable, rdesktop will wait very long till it responds. When you
click the window away, one would expect the program to terminate, but still
it keeps waiting - this is very confusing. Is it possible to terminate the
entire program when the window is closed?
Greets,
--
Arend van Beelen jr.
http://www.liacs.nl/~dvbeelen/
"So if you want my address, it's number one at the end of the bar."
- Marillion

On Friday 20 December 2002 06:22 pm, you wrote:
> Sure thing.
>
> Fred
Fred I've been able to reproduce this after many full screen toggles.
When I turned off the 'focus new windows' option in blackbox. Can you tu=
rn=20
this option on to see if it fixes the problem.
Jay

Sure thing.
Fred
On Thu, 2002-12-19 at 20:41, Jay Sorg wrote:
> Hi Fred,
>
> One thing that comes to mind is foucing the window when the
> mouse is moved if it is not focused in full screen mode.
> A big problrm that came up latey was the full screen rdesktop
> sceen saver(with password) problem.
> We can't do what you ask with that last patch.
> Can I send you a patch to test :)
>
> Jay.
--
Fred Potter <fred@...>

cmars wrote:
> If I were to bundle rdesktop in a commercial software package and
> sell it, what are the licensing implications for commercial use of
> rdesktop, for both me and my customer? Could Microsoft demand
> outrageous licensing fees for each non-Windows TS client? I can't
> find a straight answer to licensing issues...
You'll need a CAL and a TS-CAL. According to Microsofts Swedish customer
support, it's OK to use rdesktop to connect to Windows Terminal Servers.
> Has anyone deployed rdesktop commercially,
Yes, we have. Also, if I'm not mistaken, the Neoware EON terminals
includes rdesktop.
/Peter

cmars wrote:
> What is the status of keyboard mapping on non-PC systems? I want to
> use Sun type 4, 5, and 6 keyboards with rdesktop, and also HP-UX.
The latest version, 1.2beta1, should work on all X11 systems. I've heard
of some problems on IRIX, but in general it should work.
> It seems to me (and this might be extremely naive) that X11 somehow
> maps all these different keys to a common mapping in X11. For
> example, if I press Ctrl or Alt on a Sun workstation, a remote app on
> a Linux PC reads the key correctly. And the reverse is true, a Linux
> PC maps its keys correctly to a Sun app (well, maybe not all the Sun
> keys, but at least the important ones). So, this common X11 mapping
> ought to be able to be mapped to the Microsoft PC key bindings,
> right? You might need one per locale, but all UNIX platforms should
> use this common X11 keyboard interface. What am I missing?
Yes. The problem was that earlier versions of rdesktop didn't use the
common X11 interface (keysyms), but rather machine-dependent keycodes.
I've rewritten rdesktop to use keysyms instead. One problem is that RDP
uses keycodes (sort of) over-the-wire, so rdesktop needs to translate
from keysyms to keycodes (scancodes). The latest version does this.
One remaining problem is that not all translation maps are completed.
Any help with this is appreciated.
/Peter,
rdesktop team

Hi Robert,
On Fri, 20 Dec 2002, Robert Kaempf wrote:
> - IRIX 6.5, german keyboard
> - Win2k Terminal-Server, configured with german keyboard
> - rdesktop 1.2beta1 (including some CVS updates: colormap option)
>
> Pressing the next key q (for an @) generates an release (!) extended
> Scancode 0x38, so AltGR is now "off" again on the PC - and so a "q"
> is typed. :-(
>
The problem here is that "@" on an English keyboard is Shift+"2". So, if
you want to send this to an English Terminal Server (I guess you didn't do
"-k de"), rdesktop *has* to release AltGr and press Shift.
Hope this helps,
Dscho

Hi Fred,
> I'm using blackbox. I hadn't even tried it in other
> window managers. Also, I do not use the -K option to
> keep window manager bindings.
I installed blackbox 0.61 and I can't get the toggle fullscreen to fail. =
I=20
changed a few setting but it always works.
> What causes the focus out? Is the window manager always
> responsible for setting focus? In that case, when we're
> going fullscreen and completely overriding the window
> manager, a focus out would have to occur... correct?
I don't get the focus out, I was hoping to debug this.
Can you tell me what version or options you have set.
Jay

On Wednesday 18 December 2002 09:27, cmars wrote:
> If I were to bundle rdesktop in a commercial software package and sell it,
> what are the licensing implications for commercial use of rdesktop, for
> both me and my customer? Could Microsoft demand outrageous licensing fees
> for each non-Windows TS client? I can't find a straight answer to
> licensing issues...
>
> Perhaps a precedent might be found in the way Citrix clients are
> licensed... If you buy Citrix, do you have to buy TS client licenses from
> Microsoft? Or is that bundled with the cost of Citrix?
>
> Of course, any modifications to the rdesktop binary will be contributed to
> the project in accordance with the GPL. It is the whole Microsoft factor I
> am unsure about.
>
> Has anyone deployed rdesktop commercially, or at least researched rdesktop
> licensing issues with M$?
>
> Thanks
> Casey
Well, I have looked at a few commercial thin clients who all seem to utilize
rdesktop for the RDP connectivity.
As for licencing, you are still forced to by a CAL for every person/terminal
(depending on your licencing - either seat or concurrent) from Microsoft.
--
Regards,
Adrian Snyman
/* Beat me, Whip me, Make me use Windows */
==================
The views expressed in this email are, unless otherwise stated, those of the author and not those of Supply Chain Services or its management. The information in this e-mail is confidential and is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted in reliance on this, is prohibited and may be unlawful.
Whilst all reasonable steps are taken to ensure the accuracy and integrity of information and data transmitted electronically and to preserve the confidentiality thereof, no liability or responsibility whatsoever is accepted if information or data is, for whatever reason, corrupted or does not reach its intended destination.

If I were to bundle rdesktop in a commercial software package and sell it, what are the licensing implications for commercial use of rdesktop, for both me and my customer? Could Microsoft demand outrageous licensing fees for each non-Windows TS client? I can't find a straight answer to licensing issues...
Perhaps a precedent might be found in the way Citrix clients are licensed... If you buy Citrix, do you have to buy TS client licenses from Microsoft? Or is that bundled with the cost of Citrix?
Of course, any modifications to the rdesktop binary will be contributed to the project in accordance with the GPL. It is the whole Microsoft factor I am unsure about.
Has anyone deployed rdesktop commercially, or at least researched rdesktop licensing issues with M$?
Thanks
Casey

What is the status of keyboard mapping on non-PC systems? I want to use Sun type 4, 5, and 6 keyboards with rdesktop, and also HP-UX. The HP-UX system uses a USB keyboard, but the key mappings on all of the above are scrambled when I open an rdesktop session.
I have been digging thru the past archives, finding different workaround solutions to this problem (keycodes, patches to rdesktop, etc.). What is the current best solution for non-PC keyboard support? If it is a patch to the sources, where can I download it?
It seems to me (and this might be extremely naive) that X11 somehow maps all these different keys to a common mapping in X11. For example, if I press Ctrl or Alt on a Sun workstation, a remote app on a Linux PC reads the key correctly. And the reverse is true, a Linux PC maps its keys correctly to a Sun app (well, maybe not all the Sun keys, but at least the important ones). So, this common X11 mapping ought to be able to be mapped to the Microsoft PC key bindings, right? You might need one per locale, but all UNIX platforms should use this common X11 keyboard interface. What am I missing?
Casey

Jay,
I'm using blackbox. I hadn't even tried it in other
window managers. Also, I do not use the -K option to
keep window manager bindings.
What causes the focus out? Is the window manager always
responsible for setting focus? In that case, when we're
going fullscreen and completely overriding the window
manager, a focus out would have to occur... correct?
I'm clueless when it comes to Xlib, but I'm trying to
pick it up. Am I thinking correctly?
Also, how would you go about checking for the screensaver
in a universal, desktop environment-neutral way?
Thanks,
Fred
On Mon, 2002-12-16 at 03:28, Jay Sorg wrote:
> Actually there is a focus out we want to ungrab the keyboard with in full
> screen mode.
> The one that comes when the screensaver starts.
> I'll have to look at this some more.
> Fred, What desktop manager are you using?
>
> Jay
>
> On Monday 16 December 2002 09:11 am, Jay Sorg wrote:
> > > Here's a small patch to fix a problem with toggling
> > > in and out of full screen with the CVS version.
> >
> > Thanks, I'll submit it today.
> > You're right, there should never be a focus out in full screen.
> >
> > Jay
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:
> > With Great Power, Comes Great Responsibility
> > Learn to use your power at OSDN's High Performance Computing Channel
> > http://hpc.devchannel.org/
> > _______________________________________________
> > rdesktop-devel mailing list
> > rdesktop-devel@...
> > https://lists.sourceforge.net/lists/listinfo/rdesktop-devel
--
Fred Potter <fred@...>

Actually there is a focus out we want to ungrab the keyboard with in full=
=20
screen mode.
The one that comes when the screensaver starts.
I'll have to look at this some more.
Fred, What desktop manager are you using?
Jay
On Monday 16 December 2002 09:11 am, Jay Sorg wrote:
> > Here's a small patch to fix a problem with toggling
> > in and out of full screen with the CVS version.
>
> Thanks, I'll submit it today.
> You're right, there should never be a focus out in full screen.
>
> Jay
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> rdesktop-devel mailing list
> rdesktop-devel@...
> https://lists.sourceforge.net/lists/listinfo/rdesktop-devel

> Here's a small patch to fix a problem with toggling
> in and out of full screen with the CVS version.
Thanks, I'll submit it today.
You're right, there should never be a focus out in full screen.
Jay

Hi,
Here's a small patch to fix a problem with toggling
in and out of full screen with the CVS version.
The CVS version supports toggling with CTRL-ALT-ENTER,
unlike 1.0.0 and 1.1.0 which require a patch.
The problem was, whenever you toggled from window
to fullscreen, rdesktop was Ungrabbing the keyboard
and no longer capturing any keyboard input.
I'm new to x11 programming, and I'm not sure if
this was the best way to fix it. I still wasn't
sure why a FocusOut event was even being generated.
In my mind, fullscreen is certainly in focus, and
so it didn't make sense to see a FocusOut event.
Anyways, this works and is tested.
--
Fred Potter <fred@...>
--- xwin.c.orig 2002-12-14 02:48:46.000000000 -0800
+++ xwin.c 2002-12-14 02:48:58.000000000 -0800
@@ -626,6 +626,8 @@
case FocusOut:
if (xevent.xfocus.mode == NotifyUngrab)
break;
+ if (fullscreen)
+ break;
focused = False;
if (xevent.xfocus.mode == NotifyWhileGrabbed)
XUngrabKeyboard(display, CurrentTime);

After further investigation, it seems rdesktop uses 4 bits color in the
session when the Xserver itself has only 8 bits colors.
I'll mail this to the -devel mailinglist too....since it's a problem in
the cvs branch.
Gr,
Ivo van Dongen
-----Original Message-----
From: "vdongen" <vdongen@...>
Date: Wed, 04 Dec 2002 15:00:47 +0100
Subject: very dark desktop
I upgraded today from an older version of rdesktop to the latest
version 1.1.0cvs-something.
When I restarted the session.....the screen turns very dark. The
session however works fine....does the new version depend on other libs
then the previous?
Or is there a problem if there is no window manager on the X desktop?
Running X 4.2.1
Greetings,
Ivo van Dongen