Yaakov (Cygwin Ports) wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Jon TURNEY wrote: >> This throws up a strange linkage problem: XWin.exe links fine, but all the >> other .exes produced (e.g. Xvfb.exe, Xnest.exe) fail to link with the >> GetTickCount reference in libos.a unresolved. XWin.exe is presumably >> different because it has references to GetTickCount in the .o files linked >> to make the final executable. I don't understand the intricacies of cygwin >> linking to guess why the linker can't resolve this symbol from kernel32 in >> this case. > > Because os/utils.c doesn't include windows.h (and it can't, because > you'll get an error from mixing of winsock2.h and cygwin socket.h > headers), and GetTickCount is exported in libkernel32 as stdcall > [EMAIL PROTECTED] So adding the stdcall declaration of GetTickCount in > os/utils.c builds, and that seems to fix the right-click and grab > problems. (I'm a bit curious as to why the gettimeofday fallback > doesn't work, though.) Thanks; I've added a modified patch to SVN.
gettimeofday() returns the time since the start of the UNIX epoch. GetTickCount() returns the time since the start of the uptime. The timestamps from clients seem to be uptime epoch, although I don't know exactly where this comes from. (Perhaps these are timestamps copied from mouse/keyboard events coming from winmouse.c/winkeybd.c, which uses GetTickCount() directly) When the server uses the UNIX epoch time, this doesn't work well. dix/selection.c:ProcSetSelectionOwner was always falling into the case "If the client's time stamp is in the future relative to the server's time stamp, do not set the selection, just return success. " If you look at what ClientTimeToServerTime() does, if the time is more than 2^31 seconds in the past, it assumes an overflow and adds 2^32 seconds onto it (somewhat confusingly called a 'month' :-) ) (and this is always going to be true at the moment, assuming reasonable values for the uptime, as we are more than 2^31 seconds since the start of the UNIX epoch) Sorry if that's not a very clear explanation. Hope that satisfies your curiosity. :-) >> I agree that enabling XVideo doesn't make much sense or do anything useful, >> I had it off in my .cygport, so this patch also changes the .cygport to add >> --disable-xv to the configuration. > > configure seems to imply that there is support with the XWIN_XV > conditional, which is used in hw/xwin/Makefile.am, but the corresponding > compiler flag seems to be unused. Too bad; a lot of multimedia programs > use Xv. :-( I'll disable Xv and XvMC accordingly. Oh, yes, there's even some code in winvideo.c, clearly doesn't do anything though. Someone must have had a cunning plan.... > I've noticed a few other (more minor) issues: > - - transparent backgrounds are black in window icons > - - multiwindow mode ignores WM hints to not show title bar I wonder if these are regressions against 6.8.99 or not. There's a bunch of fixes to icon handling and wm hint handling in Xming I am looking at importing, which might well help with problems like these. It would be helpful if you could mention specific apps that have these problems, and I'll take a detailed look. > - - mplayer complains that shared memory isn't available (but xdpyinfo > shows MIT-SHM extension is enabled) if launched with DISPLAY=:0.0, but > doesn't complain if launched with DISPLAY=:1.0 (where both are XWin). Odd. I can't reproduce this. > - - what's the story with Xinerama? Xinerama is disabled in the 6.8.99 server In the 1.3 server, even if you configure with -disable-xinerama, randr emulates xinerama if you only have one screen, so you still see XINERAMA in the list of extensions (hence my earlier confusion about -disable-xinerama not appearing to do anything) Xinerama isn't particularly useful for XWin, -multiplemonitors causes the X screen to span the entire windows desktop (which is the default in -multiwindow mode) I guess there are some obscure scenarios where Xinerama might be useful, if you had multiple screens and wanted an X desktop which only used some (but more than one) of them Building with --enable-xinerama and launching X with +xinerama, I discover the other issue: we don't have a way to configure the relative position of the screens (normally this information is provided by the ServerLayout section in xorg.conf), so it appears all the monitors end up positioned with the same origin, which isn't very useful. I suppose we could get that information via some Win32 API, but I presume it's meant to be constant, so it wouldn't make sense for modes where the X server is contained in a native window which can be repositioned) I think Xinerama is being deprecated upstream, improvements in randr will make it obsolete. So, I think I'd suggest --disable-xinerama for the configuration at the moment. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Cygwin-ports-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cygwin-ports-general
