Re: [PATCH] Xi: check all handlers before applying property changes.

2008-10-08 Thread Peter Hutterer
On Wed, Oct 08, 2008 at 08:11:26AM +0200, Simon Thum wrote: Peter Hutterer wrote: The current code exposes to inconsistent updates, i.e. if handler N succeeds but handler N+1 fails in setting the property, an error is returned to the client although parts of the server now behave as if the

Re: Does touchpads have buttons?

2008-10-08 Thread Peter Hutterer
On Tue, Oct 07, 2008 at 11:48:14PM +0200, Søren Hauberg wrote: Okay, just wasn't sure if I missed anything. I had a little time to test today, and things didn't work that well for me. I tried using the parameters (min_x, max_x, ...) that worked with my original patches, and evtouch, and they

Re: [PATCH] Xi: check all handlers before applying property changes.

2008-10-08 Thread Simon Thum
Peter Hutterer wrote: Axis range changes are one example I can think of. The driver needs to update it for axis inversion, the server for scaling. Hmm - that essentially forbids moving inversion into the server (which could be done), because we'd never know if the driver wouldn't also do it. But

Re: [PATCH] Xi: check all handlers before applying property changes.

2008-10-08 Thread Peter Hutterer
On Wed, Oct 08, 2008 at 09:12:44AM +0200, Simon Thum wrote: Peter Hutterer wrote: Axis range changes are one example I can think of. The driver needs to update it for axis inversion, the server for scaling. Hmm - that essentially forbids moving inversion into the server (which could be

Re: Looking for registers reference for Oak OTI64111 (Spitfire)

2008-10-08 Thread Volodymyr Buell
On Wed, Oct 8, 2008 at 3:28 AM, Alex Villací­s Lasso [EMAIL PROTECTED] wrote: Recently I dug up a very old graphics card, an Oak Spitfire OTI-64111 by Oak Technologies. After looking up information for it in Google, I found that there is no specific driver for xorg (although there are plenty of

[no subject]

2008-10-08 Thread Benjamin Wech
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I looked up your faq about a possibly release of a working SIS 771/671 3D driver, but haven't found an affirmative answer. So I have to ask when it would be possible to use opengl/3D with this chip considering the fact it seems to be available

XTerm exits immediatly with self-compiled xorg

2008-10-08 Thread Clemens Eisserer
Hello, I am currently trying to build xorg from git, and it mostly works except some font stuff. When I try to start xterm it quits immediatly with the following messages: The XKEYBOARD keymap compiler (xkbcomp) reports:^M Warning: Type ONE_LEVEL has 1 levels, but RALT has 2 symbols^M

Re: [PATCH] [pixmap] rename/convert devKind and devPrivate fields

2008-10-08 Thread Maarten Maathuis
On Tue, Oct 7, 2008 at 8:04 PM, Maarten Maathuis [EMAIL PROTECTED] wrote: These names are supposedly historical, but everyone seems to use them for the same purpose. I am aware this may require a few minor changes to (for example) exa drivers with driver based memory allocations. I personally

Re: [sis 671/771 drivers]

2008-10-08 Thread Paulo Cesar Pereira de Andrade
Benjamin Wech wrote: Hi, I looked up your faq about a possibly release of a working SIS 771/671 3D driver, but haven't found an affirmative answer. So I have to ask when it would be possible to use opengl/3D with this chip considering the fact it seems to be available for Windows, and

Multiple Visuals in Server

2008-10-08 Thread Craig Zimmerman
Hi, I am trying to figure out how to configure my X server to create multiple visuals. When I ran xdpyinfo, it returned 57 visuals 56 had a depth of 24, and one had a depth of 32. I was hoping to get at least one visual of depth 8 and one visual of depth 16. Is this possible? If so where

Re: [PATCH] Xi: check all handlers before applying property changes.

2008-10-08 Thread Peter Hutterer
On Thu, Oct 09, 2008 at 03:20:36AM +0200, Simon Thum wrote: So your point is to never have properties in the driver that could be in the server? This may be tough, as drivers have a quicker turnover time, and features can get added easier. Well, against double-handling a prop in general.