Wine Traffic #9 For 20 Sep 1999

on Win95 at least WSOCK32 uses a trick to be able to wait on sockets using WaitForMultipleObjects: there's an undocumented KERNEL32 routine CreateSocketHandle which returns a handle to a K32OBJ of type K32OBJ_SOCKET (== 17).

Couldn't we tell the window manager that we don't want any decorations and paint our own window (look at xmms for example). If we run wine without -managed the look is correct, but not the behaviour.

modifying the unmanaged mode (or maybe add a new mode) so it doesn't set override-redirect on top-level windows, but instead lets the WM manage those windows just like in managed mode, except it uses some (yet to be defined) hints to tell the WM to remove all frame decorations. Except for that, all painting would be done exactly like in the unmanaged case...

of course, we could always rely on the user to select that mode only if supported by the WM, but some kind of automatic fall-back would still be nice...

We've been looking at the font issue quite closely for the last few weeks, and we have explored a couple of possibilities.

First of all, here are the primary problems we see with fonts on WINE:

1. Can't get at the outline data to support GetGlyphOutline call
2. Various font sizing and metrics issues
3. No support for antialiasing
4. X font system is very confusing and hard to set up for the average user.

A/ Link directly to FreeType (note that FreeType 2.0 supports Type1 fonts in addition to TrueType).

We've already done some experimentation along these lines and we have a preliminary implementation of GetGlyphOutline that works using direct calls to FreeType.

FreeType would solve (1) and (2) quite easily - we would just get the info directly from FreeType. It would introduce another problem though: if we use FreeType to get metrics and outlines, but X to render the fonts (through something like xfsft), subtle differences crop up between the X-rendered font and the numbers we get back from FreeType.

We could solve this by using FreeType for rendering as well, which would also solve issue (3), but at the expense of making remote display much slower than it has to be. If we did that, we would also solve issue (4) since all the TT fonts would be in a standard place such as /usr/share/fonts/truetype. If we didn't, the user is still stuck with configuring an X server.

Finally, there's the TrueType patent issue which has yet to be resolved. (Please put up your hand if you hate software patents)

B/ Encourage development of extensions to the X Font Server protocol that would enable us to get access to the font outlines.

This would solve (1) and (2), while leaving (3) and (4) unresolved. Note that there was some work done on the 'XAnti' extension for XFree 4.0, but I believe that it was abandoned.

We've actually had some contact with a vendor that has a font server that implements these kind of extensions along with an SDK for getting at the outlines. The code would not be free though. Their work also solves issue (4) in a different way.

How do people feel about adding optional support for a non-free library that provides this functionality? Alexandre, if we did work to support such a library (ifdefed, of course), would you allow that work into CVS, or would we have to keep a seperate branch ourselves?

My hope is that the vendor would be willing to release the information about the protocol they're using so that XFree and other X server developers could support the extension protocol themselves in the future....

As far as getting font outlines and doing font management, there's an alternative to building the added functionality into an XFS protocol extension. You can talk to the font server via a side channel. When I last looked at this, I thought there was enough flexibility in an unmodified xfs (with tt support) for our purposes, managing fonts by changing the config file and directing xfs to reread it, and maintaining a table of font file to Windows font correspondances, to allow things like outlines. I never got to a proof of concept however. My understanding of the commercial offerings was that they use a side channel as well, rather than building an extension to the XFS protocol, but I could be wrong.

The server is a standalone pure XLib application. The makefile builds a target called "wineclipsrv". wineclipsrv takes one command line argument which is a bit mask of the selection types to be acquired. Currently we just support two selections PRIMARY (internal mask value 1) and CLIPBOARD (internal mask value 2). If no argument is supplied the server aquires all selections. (mask value 3)

When the server is started it first queries the current selection owner of the specified selections for the TARGETS selection target. It then proceeds to cache all the formats exposed by TARGETS. If the selection does not support the TARGETS target, or if no target formats are exposed, the server simply exits. Once the cache has been filled, the server then actually acquires ownership of the respective selection and begins fielding selection requests. Selection requests are serviced from the cache. If a selection is lost the server flushes its internal cache, destroying all data previously saved. Once ALL selections have been lost the server terminates.

Now when Wine terminates, we check if Wine owns any selections. If it does we spawn the server with the appropriate selection masks. This captures the selection data from Wine and takes over the selection.

I started some days ago to add DGA 2.0 support to DirectDraw (to use the new possibilities like depth / resolution switching and hardware blits with and without transparencies).

By doing a small test program, I found out that, whatever I do, when I start using DGA, all mouse movements reported by XMotionEvents are relative movements.

The game I am testing with (Baldur's Gate) uses DirectDraw for its graphics but standard USER calls for its mouse input (to be more precise, USER.17 GetCursorPos16).

When I test the game with DGA, the mouse does not move at all. This is because as long as DGA is enabled, XQueryPointer always returns the position of the mouse before entering DGA.

As GetCursorPos16 calls EVENT_QueryPointer, I concluded that I need to add a new driver specific to this case that would use all the XMotionEvents to compute the absolute mouse position by adding all the relative events and clip to the screen size.

to fix this in our USER itself, instead of hacking the driver: on real Windows, USER must cope with whatever it gets passed to its mouse_event routine. In particular, USER must cope if the mouse_event routine is called only with relative events. In this case it is the task of USER to add up the relative events so as to track the absolute position!

So, what would you say to this solution: throw out completely the EVENT_QueryPointer routine. Instead, create USER-global variables holding the current mouse position; at all places where QueryPointer is currently called, use those variables instead. The variables are filled in the mouse_event routine, which is furthermore changed to cope with both absolute and relative mouse events. In the case of absolute events, it simply sets the global variables to the given values, while in the case of relative events, it keeps adding them up.

Next, modify the X11DRV_EVENT driver to send relative mouse events if DGA is active (it should know that ...), and absolute mouse events whenever possible (just like now).