Re: gcc3 source code in xorg-server-1.6.1.901

2009-06-09 Thread olafBuddenhagen
Hi, On Fri, Jun 05, 2009 at 08:20:46AM -0400, Thomas Dickey wrote: One point to be made is that the source which was added to the tree has additional restrictions which do not apply to other files. It is not really source code. It is a .c file, but a generated one. The real source is the .y.

Re: gcc3 source code in xorg-server-1.6.1.901

2009-06-09 Thread Thomas Dickey
On Mon, 8 Jun 2009, olafbuddenha...@gmx.net wrote: Hi, On Fri, Jun 05, 2009 at 08:20:46AM -0400, Thomas Dickey wrote: One point to be made is that the source which was added to the tree has additional restrictions which do not apply to other files. It is not really source code. It is a .c

Re: Road map for remaining pixman refactoring

2009-06-09 Thread Simon Thum
Soeren Sandmann wrote: Simon Thum simon.t...@gmx.de writes: Soeren Sandmann wrote: - bits_image_fetch_pixels() then calls a low-level pixel fetcher whose job it is to convert from whatever the image format is to PIXMAN_a8r8g8b8. Just a question: does that imply algos will

Re: set_mode_major vs RandR transforms

2009-06-09 Thread Matthias Hopf
On Jun 08, 09 22:27:03 -0700, Keith Packard wrote: 1) set_mode_major no longer sees the current state of the hardware. That was already partially true -- the The driver can track the state itself if it needs to. I don't see any issues here. 2) existing set_mode_major implementations set

Re: [PATCH] xkb: Don't press+release keys on key events

2009-06-09 Thread Matthias Hopf
On Jun 04, 09 21:54:42 +1000, Daniel Stone wrote: As Peter said anyway, driver-triggered key repeating is deprecated, and the XKB autorepeat mechanism should be used. I'm not really happy with the way actions work at the moment, so if you want to file a bug and assign it to me and Cc Peter,

Re: Road map for remaining pixman refactoring

2009-06-09 Thread Soeren Sandmann
Simon Thum simon.t...@gmx.de writes: For the more artistic cases directed at perceptual qualities (like some gradients, but not the WM shadow gradient!), luma modulation is of course desirable. But there are better tools for this purpose, like the L*a*b* space. So why go to such great lengths

Re: Pixman Accessors

2009-06-09 Thread Maarten Maathuis
Have you benchmarked this? I know it wasn't fast, but if it becomes even (significantly) slower that's not very nice. I'm not near a system where i can test this for the forseeable future. Maarten. ___ xorg-devel mailing list xorg-devel@lists.x.org

Re: Pixman Accessors

2009-06-09 Thread Maarten Maathuis
Also, making a copy of non-cached memory can be painful. VRAM is typically write combined. The very advantage wfb is supposed to give is copyless access, taking that away could make it unbearable, instead of just slow. This should definately be tested first. Maarten. On Tue, Jun 9, 2009 at

Re: Pixman Accessors

2009-06-09 Thread Maarten Maathuis
I had a closer look, and the only worry is fbRasterizeEdges. The composite case is less worrying. Maarten. ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel

Re: Pixman Accessors

2009-06-09 Thread Soeren Sandmann
Maarten Maathuis madman2...@gmail.com writes: I had a closer look, and the only worry is fbRasterizeEdges. Ok, I'll buy that it could be a real performance issue if the mask ends up thrashing back and forth between host and video memory. However, trapezoid rasterization always happens to a

Re: [ANNOUNCE] udlfb 0.2.2 and xf86-driver-displaylink 0.2

2009-06-09 Thread Adam Jackson
On Fri, 2009-06-05 at 15:14 +0200, Roberto De Ioris wrote: Hi all, there is a new version of udlfb (displaylink linux framebuffer module) and of the related xorg driver. Changes are: - preliminary supports for double buffering (mainly intended for smooth video playing) - rle compression

Re: [ANNOUNCE] udlfb 0.2.2 and xf86-driver-displaylink 0.2

2009-06-09 Thread Roberto De Ioris
On Fri, 2009-06-05 at 15:14 +0200, Roberto De Ioris wrote: Hi all, there is a new version of udlfb (displaylink linux framebuffer module) and of the related xorg driver. Changes are: - preliminary supports for double buffering (mainly intended for smooth video playing) - rle compression

Re: Temporary resolution changes?

2009-06-09 Thread Eric Anholt
On Wed, 2009-05-20 at 10:59 +0100, Luke Benstead wrote: Hi all, I recently had a discussion with a Wine developer and I mentioned that I had on several occasions been left at a low resolution when a fullscreen application crashes. He said that Wine could perhaps code in a fix which

Re: Pixman Accessors

2009-06-09 Thread Aaron Plattner
On Tue, Jun 09, 2009 at 09:50:05AM -0700, Soeren Sandmann wrote: Pixman has a feature where you can set accessor functions on an image and all pixel access will then go through those functions. It's used exclusively for wfb. Until now this was implemented by compiling the pixel accessors

[RFC][PATCH] dix/resource: fix use after free in resource code with DRI

2009-06-09 Thread Dave Airlie
LookupClientResourceComplex is used by DRI1 code to find and free a DRI drawable in a callback, however when the DRI code returns this-value is now pointing at freed memory. It seemed easiest to store the value to a temporary and return it afterwards. Another option might be a new