[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xougen] Regarding server side widgets

From: Craig Ringer
Subject: Re: [xougen] Regarding server side widgets
Date: Thu, 28 Aug 2003 09:01:44 +0800
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030511

The problem with DRI is that it _ONLY_ works on the local machine, it isn't just and restriction, it just can't work if the client isn't on the same machine.

Yes. But other similar interfaces/protocols could be possible, which can do it (of course much slower). It should be the job of the client
library to negotiate with the server, which protocol is the best.

Why? It's an X server, and it seems sensible to stick to the basic task of being a /good/ X server, not a multi-protocol display server. Other display protocols, if any, could easily be handled by an X client doing translation on the same machine as the X server (think VNC).

Multi-protocol client support strikes me as excessively complex, and I personally don't see any need. X11 can be a little too low level at times, but this is improved by the RENDER extension, and Xr / Cairo should provide some interesting possibilities as well. The key point is that it can ALL be done with X11 extensions, retaining backward compatability. Why break it when it works well?

In fact, if you want to write an XWIDGET extension, it might be quite possble within the existing X11 protocol. I really don't know enough about the innards of the protocol to say. Perhaps if you could say "here's an example implementation - these tests show a significant improvement, and clients can automatically back to using libxwidget to send basic X11 requests if the server doesn't support XWIDGET" then you might find folks more interested.

I've expressed interest previously in built-in VNC support for the X server... but for the X server to provide a VNC server (note overloaded meaning of server) that can be used to view the X server's frame buffer remotely. An entirely different thing, and if it's best done outside the X server, then cool - but currently it'd be a handy thing to have available universally.

I can't claim to know overly much about Xlib, but from what I've been hearing it's a bit of a pain to code against. So perhaps there's an argument for an "xlib2" or something - but that need not break or even touch existing xlib code, since it'd just be a separate client-side interface, and wouldn't need to have anything to do with any /specific/ X server. In other words, it's not an issue for a project that's currently focusing on the X server only.

There are a lot of cool possibilities with X11, but it strikes me that the real issues right now are not with the protocol or such, but with driver availability and the difficulty of getting updated drivers for XFree86 as things stand. Xouvert can improve that by providing separately packaged drivers, and IMHO that'd be an important step. I feel rather stupid every time I have to tell someone that their graphics chipset isn't supported under distro blah, so they'll have to update their distro or reinstall the entirity of XFree86 (w/o suitable packages, just drop it in and hope it works as expected). Sure, it's possible and for many not that hard - but it's unfortunate that it's needed at all when XFree86 4 had so much work done on it to make sure drivers would be portable between versions.

Craig Ringer

reply via email to

[Prev in Thread] Current Thread [Next in Thread]