Peter Harris wrote:
but xlib doesnt support an alpha channel (and the freerunner has only 16
bits per pixel). is there an easy way to do transparency (one
transparent color is enough) with xlib or a toolkit which builds on it?
If you can easily extract that color into a 1-bit bitmap,
Thanks Peter for your answer.
Here is the event sequence when I tap the screen:
$ evtest /dev/input/event3
Input driver version is 1.0.0
Input device ID: bus 0x3 vendor 0xdfc product 0x1 version 0x305
Input device name: USB Touchscreen 0dfc:0001
Supported events:
Event type 0 (Sync)
Event
On Wed, 2010-07-21 at 11:21 +, hindm...@netzero.com wrote:
TL;DR
So, somewhere between Fedora 11 and Fedora 13 and hoo nose what
version of hoo nose what library(s) the creation or handling of the
completion events caused by XShmPutImage(..., True) stopped. I've
read the docs, Googled
On Wed, 2010-07-28 at 05:36 +0400, sergio wrote:
Hello.
Is it possible make video driver with which subpixel rendering will not
work? Or only xrender acceleration depends on driver?
The RENDER extension is initialized when the driver calls
fbPictureInit(). All known shipping drivers do
On Thu, Jul 22, 2010 at 6:10 PM, Lowell Alleman wrote:
Here is a gdb session with the crash. Does any of this help me?
Tormod, you'r a Ubuntu guy, right? Any idea why I'm getting a message about
the r300_dri.so symbols report a CRC mismatch? I have applied the latest
radeon drivers from
Sending this to the XOrg list, because of the possible involvement of
the X configurations, as noticed in some web searches.
=
KUbuntu 10.4 on ~2004 Compaq laptop, using alternate installer cd. In
the USA, probably a USA build type of laptop keyboard. This is probably
the text mode installer
On Thu, Jul 29, 2010 at 02:26:39PM -0700, giovanni_re wrote:
Sending this to the XOrg list, because of the possible involvement of
the X configurations, as noticed in some web searches.
=
KUbuntu 10.4 on ~2004 Compaq laptop, using alternate installer cd. In
the USA, probably a USA build
This case was missing and could cause corruption if we flush damage events
to a client before the driver gets to submit the rendering from the
callback chain.
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
os/io.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git
On Thu, Jul 29, 2010 at 12:05:07PM +0200, Javi wrote:
Thanks Peter for your answer.
Here is the event sequence when I tap the screen:
$ evtest /dev/input/event3
Input driver version is 1.0.0
Input device ID: bus 0x3 vendor 0xdfc product 0x1 version 0x305
Input device name: USB
On Thu, 29 Jul 2010 18:53:34 -0400, Kristian Høgsberg k...@bitplanet.net
wrote:
This case was missing and could cause corruption if we flush damage events
to a client before the driver gets to submit the rendering from the
callback chain.
Seems like this is a good candidate for 1.9, yes? Is
2010/7/29 Dave Airlie airl...@gmail.com:
Also, there is one more call to FlushClient in CloseDownConnection; any
reason we shouldn't be invoking the FlushCallback there too? More from a
sense of completeness than a chance that it's going to actually matter.
Yes, that sounds fine. And I just
Change the damage extension reporter to queue up events after we chain
to the wrapped functions. Damage events are typically sent out after
the rendering happens anyway, since we submit batch buffers from the
flush callback chain and then flush client io buffers. Compositing
managers relie on
We were missing the callback in a couple of places. Drivers may use
the flush callback to submit batched up rendering before events (for
example, damage events) are sent out, to ensure that the rendering
has happend when the client receives the event.
Signed-off-by: Kristian Høgsberg
13 matches
Mail list logo
