Cygwin/X

X Windows - on Windows!

Development - To-Do List

See also the Cygwin/X category in sourceware.org bugzilla

Following is a list of open tasks on the Cygwin/X project:

Please note that this list is in no particular order, and presence on this list doesn't guarantee that a task is desirable, practical or even possible. Feel free to get started, though...

Summary Description
native IME - XIM bridge

Kensuke Matsuzaki wrote some clever code which provides a bridge between Windows native IME and XIM. This should be brought up to date and integrated.

Animated cursors

Are we converting every frame of an animated cursor every time it appears? Build on the work in this commit to allow the XWin DDX visibility of the animated cursor, so it can do something cleverer.

Regression and stability Testing

Upgrade to modular X11R7.4 has inevitably introduced some bugs. Cygwin 1.7 seems to have brought a few new issues as well. We need to find them and fix them.

-mwextwm mode and xwinwm

Needs fixing to build, and work again. Should build and work now, but needs looking at to see what it lacks compared to the internal WM. Is it possible to replace the internal WM with this, in the long term?

Command line parameters

-help, the man page, and the user guide all need updating and synchronizing with what the source actually does

XVideo?

The XVideo extension is currently disabled. There is some skeleton code in the server, but it doesn't do anything yet. Possible to map Xv/XvMC to some DirectX or DxVA API?

Composite

Find and fix Composite bugs in rooted mode. Cunning plans for compositing in multiwindow mode (using Win2K+ window transparency)? (Integrated WM has to become composite-aware for this). Bug #10997

Windows display size changes while running. Monitor count/position changes while running.

Use RandR (resize and rotate) to pass changes to the display size (e.g. from 1024 x 768 to 1280 x 1024) to the X Server and all running applications. This should be straightforward to do; you can use the WM_DISPLAYCHANGE handling code that is in place for detecting display changes and just pass these values to RandR to let it do its thing. Partially done at http://cgit.freedesktop.org/~jturney/xserver/log/?h=jturney-framebuffer-resize. Done in 1.8.2-1. Possibly xinerama scenarios need looking at.

Improve Windows clipboard integration

Stamp out remaining clipboard bugs.

Extend the Cygwin/X clipboard manager, to handle data types other than XA_STRING, COMPOUND_TEXT, and UTF8_STRING; for example, BITMAP, PIXMAP, etc.

User's Guide - Document .XWinrc

Documentation needs to be added to the User's Guide for Earle F Philhower III's .XWinrc mechanism. This task is greatly simplied by the fact that Earle provided comments in the example /etc/X11/system.Xwinrc file. Perhaps a pointer to 'man XWinrc' and some examples.

GUI mechanism for opening the log file

Add an item to the tray-icon right-click menu to open the log file

Adding a line like "View logfile" EXEC "xterm -e less +F /var/log/XWin.0.log" to the default XWinrc is almost enough. We need to get the correct logfile name for non-default display or -logfile options, though.

FatalError Dialog Box

Change the FatalError message box to a dialog box with helpful links?

Indirect OpenGL acceleration (AIGLX)

Testing of the implementation of indirect OpenGL acceleration using native WGL. Additional information is in the email asking for testing. Bug #10472

Detect in-use display number ports

Display number n in X11 listens on TCP port 6000 + n. As of our X Server release 4.3.0-49 we check for other instances of XWin.exe running on a given display number, but we perform no checks for other applications listening on port 6000 + n. We may not be able to atomically check port 6000 + n and start listening on it if it is not in use, but we can at least perform a sanity check with only a small window where another application could start listening on that port before we started listening on it; this would be a sufficient fix for our purposes. Other developers can help with adding command-line parameters to control this feature once the above code is finished.

Automatically assign display number

Coupled with the detection of in-use display numbers, it would be advantageous if we could optionally automatically assign an unused display number to a new instance of XWin.exe. We would need an IPC mechanism used for all instances of XWin.exe to share information about in-use display numbers, as well as a check of potentially available ports for use by other applications. Finally, this whole thing is useless if we do not have a way to query the started instance of XWin.exe for the display number that it assigned to itself; the ideal solution to this problem will likely require an external executable that has an IPC mechanism to retrieve the desired display number from all running instances of XWin.exe. We may be able to adapt the run.exe utility to query the XWin.exe instance with the same parent process id (should be the command shell that both were started from, I hope) and to then modify the environment being passed to a child process. There may be other ways to solve this problem, but anything that allows for a race between started instances of XWin.exe will be unacceptable, since an error would result in applications attaching to the wrong display.

Perhaps simply place a correctly set DISPLAY into the environment of processes started via the taskbar icon. tbh, I'm not sure what problem we are trying to solve here.

The -displayfd patch from fedora, added in 1.9.0-1 could address this issue. See this email.

Timestamp on log file entries

Add a timestamp to each line of /tmp/XWin.log, as suggested by Ehud Karni on 2004-03-03. Ehud also provided source code useful for performing such timestamping in his email. Should be written using strftime(), though. Added in 1.6.2-2

MultiWindow DirectDraw and DirectDraw NL

Blit updates from a DirectDraw shadow framebuffer to the updated Win32 window instead of blitting from a GDI shadow framebuffer. This should be trivially easy to start and should require only a single DirectDraw surface for the whole screen (I had previously said it would require one surface per Win32 window). It would be very important to just demonstrate that this can be done; clipping the blits to properly handle window z-order and such can be finished by other developers.

Emulate PseudoColor on TrueColor

Provide emulation of PseudoColor visuals (typically 8-bit palette-based visuals) on top of the default TrueColor visual (when running in 15, 16, 24, or 32 bit color depths). This will allow a lot of CAD-type applications that require PseudoColor to be run when Windows is in a color mode higher than 8 bits per pixel. The general idea here is to add checks to any copying of data between offscreen and onscreen, as well as between areas on the screen; these checks test for differing visual types and convert the pixels and colors accordingly.

See also upstream bug #4770.

DirectDraw windowed PseudoColor

Figure out a satisfactory solution for enabling DirectDraw engines to support PseudoColor visuals when running in 8 bit color modes. DirectDraw reserves the first ten and the last ten colors in each DirectDrawPalette object when running in windowed mode. Therefore, PseudoColor visuals are only supported with DirectDraw engines when running in fullscreen 8 bit color modes.

Last updated: $Date: 2011/03/21 22:05:16 $ ($Author: jturney $)

Valid XHTML 1.0 Transitional Valid CSS!