On Sun, Oct 12, 2008 at 06:17:20PM +0200, Simon Thum wrote:
Peter Hutterer wrote:
The patch I proposed does not make any guarantee over when a handler is
called. This automatically separates handlers so they cannot interfere with
each other, and dependency ordering is a nonissue, as you
Peter Hutterer wrote:
For now, the rule is that handlers should not touch anything outside of their
scope, and they cannot rely on being called in any particular order.
Fine. I think prop namespaces also could mitigate the problem, e.g.
driver.* Any plans for this?
Let's see if that works. We
On Sat, 2008-10-11 at 20:18 +0100, Colin Harrison wrote:
Hi,
There you go
--- save_base.xml.in2008-10-11 20:13:17.0 +0100
+++ base.xml.in 2008-10-11 20:13:33.0 +0100
@@ -2446,7 +2446,7 @@
_descriptionLower Sorbian (qwertz)/_description
On Sun, 2008-10-12 at 11:17 -0400, larry craig wrote:
I have an IOgear extreme KVM switch that isn't passing along my EFID
settings to xorg. I know this isn't a problem with Xorg and isn't
your problem. But I need a solution, so here's what I'm thinking...
When I plug my monitor in, all is
That's ok. Feel free to commit the fix.
Sergey
On Mon, Oct 13, 2008 at 2:49 PM, Adam Jackson [EMAIL PROTECTED] wrote:
On Sat, 2008-10-11 at 20:18 +0100, Colin Harrison wrote:
Hi,
There you go
--- save_base.xml.in2008-10-11 20:13:17.0 +0100
+++ base.xml.in 2008-10-11
Karsten Heiken wrote on Sunday, October 12, 2008 2:23 AM:
I recently bought a new notebook (Sony Vaio SR19XN) with an Intel GMA
X4500MHD graphics adapter.
The intel-driver works - but only for external monitors.
My laptop-display doesn't show anything.
The panel-backlight is active - but
Hello
Attached is a patch for the syndaemon of the synaptics driver. It prevents
the
polling of the keyboard state. Instead it uses the XRecord extension of the
Xserver for an event triggered notification of key events. Of course, there
is a fallback to the polling when no XRecord extension is
Right now Render is sort of vaguely defined when any of (src, mask, dst)
point to the same underlying drawable. This is not necessarily just
when they're all the same Picture, although that's certainly a special
case.
I'd like to have this clarified, since otherwise it becomes essentially
On Mon, 2008-10-13 at 11:01 -0400, Adam Jackson wrote:
The former is certainly way simpler, but might break some existing
application. Maybe?
It's hard to imagine it breaking anything as the current server code
does the wrong thing in this case. Given that 3D hardware doesn't
support this
On Mon, 2008-10-13 at 14:56 +0100, Sergey Udaltsov wrote:
That's ok. Feel free to commit the fix.
Applied, thanks!
- ajax
signature.asc
Description: This is a digitally signed message part
___
xorg mailing list
xorg@lists.freedesktop.org
On Sat, 11 Oct 2008 17:02:38 +0200
Matthieu Herrb [EMAIL PROTECTED] wrote:
It is an application (or maybe toolkit) level problem: handle the
event that the X display connection is being closed better than by
killing the application and allow it to reconnect to a new display
later (through
On Monday 13 October 2008 17:01:57 Adam Jackson wrote:
* PGP Signed by an unknown key
Right now Render is sort of vaguely defined when any of (src, mask, dst)
point to the same underlying drawable. This is not necessarily just
when they're all the same Picture, although that's certainly a
On Mon, 2008-10-13 at 11:01 -0400, Adam Jackson wrote:
Option B: when either of the above are true, the implementation must
act as though mask and src are constant pixel sources for the
duration of the request (ie, dst is copied aside internally to a
scratch picture, and the
On Mon, 2008-10-13 at 09:00 -0700, Carl Worth wrote:
On Mon, 2008-10-13 at 11:01 -0400, Adam Jackson wrote:
Option B: when either of the above are true, the implementation must
act as though mask and src are constant pixel sources for the
duration of the request (ie, dst is
Announcing the 1.2.2 Release of the xf86-video-radeonhd driver.
RadeonHD is the X.org X11 driver for AMD GPG (ATI) r5xx/r6xx/r7xx chipsets.
The development is driven by Novell at the time of writing, together
with a community of open source developers around this driver.
AMD provides free
Even worse, UXA has locked up my machine when starting gdm every time I
have tried using it. I'm using xf86-video-intel from git.
- Ben
Hanno Böck wrote:
Hi,
My card is:
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960
Integrated Graphics Controller (rev 0c)
Announcing the 1.2.3 Release of the xf86-video-radeonhd driver.
RadeonHD is the X.org X11 driver for AMD GPG (ATI) r5xx/r6xx/r7xx
chipsets.
The development is driven by Novell at the time of writing, together
with a community of open source developers around this driver.
AMD provides free
Harald Braumann wrote:
It is an application (or maybe toolkit) level problem: handle the
event that the X display connection is being closed better than by
killing the application and allow it to reconnect to a new display
later (through some communication protocol).
But couldn't it
Hi, folks. I remember chatting with some Intel devs around six to seven
months ago about dynamic framebuffer allocation: i.e., supporting
multiple heads without people needing to stick a Virtual line in
xorg.conf or have their distributor set a wastefully large default
framebuffer size. I recall
On Monday 13 of October 2008, Luc Verhaegen wrote:
Announcing the 1.2.3 Release of the xf86-video-radeonhd driver.
RadeonHD is the X.org X11 driver for AMD GPG (ATI) r5xx/r6xx/r7xx
chipsets.
The development is driven by Novell at the time of writing, together
with a community of open source
And on that note, how about allowing proper 3d and compositing acceleration
across screen area bigger than 2048x2048 (I believe that's the limit). It'd
be nice to be able to use Compiz/xcompmgr with two screens again like I
could with MergedFB.
___
xorg
On Mon, Oct 13, 2008 at 05:08:29PM -0400, Joel Feiner wrote:
And on that note, how about allowing proper 3d and compositing acceleration
across screen area bigger than 2048x2048 (I believe that's the limit).
With recent intel driver and mesa you should have that. (Not sure about
mesa, could be
On Mon, Oct 13, 2008 at 01:58:05PM -0700, Adam Williamson wrote:
Hi, folks. I remember chatting with some Intel devs around six to seven
months ago about dynamic framebuffer allocation: i.e., supporting
multiple heads without people needing to stick a Virtual line in
xorg.conf or have their
23 matches
Mail list logo
