Currently, drm devices go to whichever server can get them first.
See https://bugzilla.redhat.com/show_bug.cgi?id=1183654
Signed-off-by: Jonathan Dieter
---
config/udev.c | 42 +-
hw/xfree86/os-support/linux/lnx_platform.c | 9 +++
i
Dave, is this what you're looking for in moving it to config/udev.c?
I've also fixed the indentation on the #ifdefs.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/
If the BlockHandler chain is modified while it is active (the only
time it can be modified), we need to re-fetch the current value and
store it in our private for use the next time through.
Signed-off-by: Keith Packard
---
hw/xfree86/drivers/modesetting/driver.c | 1 +
1 file changed, 1 insertio
From: Dave Airlie
keithp said this was the way to do it.
Signed-off-by: Dave Airlie
---
hw/xfree86/drivers/modesetting/driver.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/xfree86/drivers/modesetting/driver.c
b/hw/xfree86/drivers/modesetting/driver.c
index 1cb0c7c..d52517d 100644
-
From: Dave Airlie
This adds glamor into the block handler call chain
in the correct place.
This should fix interactions between glamor and drivers
requiring damage from glamor.
v2: okay don't consolidate, just leave things wierd for now
remove blcokhandler in screen close.
v3: block handler wr
Dave Airlie writes:
> From: Dave Airlie
>
> This adds glamor into the block handler call chain
> in the correct place.
>
> This should fix interactions between glamor and drivers
> requiring damage from glamor.
>
> v2: okay don't consolidate, just leave things wierd for now
> remove blcokhandler
From: Dave Airlie
This adds glamor into the block handler call chain
in the correct place.
This should fix interactions between glamor and drivers
requiring damage from glamor.
v2: okay don't consolidate, just leave things wierd for now
remove blcokhandler in screen close.
Signed-off-by: Dave
From: Dave Airlie
This adds glamor into the block handler call chain
in the correct place.
This should fix interactions between glamor and drivers
requiring damage from glamor.
it retains the external API, and consolidates the
two interfaces.
Signed-off-by: Dave Airlie
---
glamor/glamor.c
Dave Airlie writes:
> From: Dave Airlie
>
> Some kernel drivers require notification that the frontbuffer
> has changed, so we add a damage collector and send the dirty
> rects in the block handler. It appears the glamor block
> handler was getting called after this one, leading to things
> gett
From: Dave Airlie
Some kernel drivers require notification that the frontbuffer
has changed, so we add a damage collector and send the dirty
rects in the block handler. It appears the glamor block
handler was getting called after this one, leading to things
getting out of sync.
I found this whil
On Wed, Jan 21, 2015 at 10:36:16AM +0100, Hans de Goede wrote:
> systemd-logind integration does not work when starting X on a new tty, as
> that detaches X from the current session and after hat systemd-logind revokes
> all rights any already open fds and refuses to open new fds for X.
>
> This m
On Wed, Jan 21, 2015 at 10:36:15AM +0100, Hans de Goede wrote:
> systemd-logind integration does not work when starting X on a new tty, as
> that detaches X from the current session and after hat systemd-logind revokes
> all rights any already open fds and refuses to open new fds for X.
typo "all
Hey,
Op 13-01-15 om 03:49 schreef Eric Anholt:
> Maarten Lankhorst writes:
>
>> Some GLES2 implementations don't support GL_UNSIGNED__REV and only
>> guarantee less fancy things to work.
>>
>> I'm only certain it fixes the GLES2 errors, but is this a sane way to handle
>> things? Or am I just
On 11/01/15 08:31, Mathias Fröhlich wrote:
>
>
> Hi,
>
>
>
> On Sunday, January 04, 2015 20:53:59 Emil Velikov wrote:
>
>> Adding Mathias and Frank Binns to the Cc list.
>
>>
>
>> So taking into account the discussion so far, including Mathias's input
>
>> that the official nvidia driver
Just a style-nit, but C requires the #ifdef at the 0 column not tabbed in,
and it looks better.
this also to me seems like it should be in config/udev.c,
since that is where all the other seat handling code lives.
Dave.
>> ---
>> hw/xfree86/os-support/linux/lnx_platform.c | 39
>> +
On Tue, Jan 20, 2015 at 04:28:40PM +0100, Hans de Goede wrote:
> Detaching from the tty causes systemd-logind to refuse service to the xserver,
> the xserver already tries to detect that it is being asked to run on the
> current tty and then automatically enables -keeptty, but this code fails if
>
Hi,
On 21-01-15 18:21, Jonathan Dieter wrote:
See https://bugzilla.redhat.com/show_bug.cgi?id=1183654
Signed-off-by: Jonathan Dieter
Thanks looks good now:
Reviewed-by: Hans de Goede
Keith can you pick this up, or do you want me to prepare a tree and send
a pull-req for this ?
Regards,
On 22/01/2015 09:17, Olivier Fourdan wrote:
The XdmcpFatal() error handler uses a string format that the
vpnprintf() routine does not understand, as a result any XDMCP
fatal error leads to a server crash:
(EE) (EE) BUG: triggered 'if (f[f_idx])'
(EE) BUG: log.c:474 in vpnprintf()
The XdmcpFatal() error handler uses a string format that the
vpnprintf() routine does not understand, as a result any XDMCP
fatal error leads to a server crash:
(EE) (EE) BUG: triggered 'if (f[f_idx])'
(EE) BUG: log.c:474 in vpnprintf()
(EE) Unsupported printf directive '*'
Rework the
Hi
On 21/01/15 19:32, patrick keshishian wrote:
Excuse my naive observation; I'm possibly missing something.
The comment states "status length is CARD8" but the header
file (If I'm looking at the correct one) states it is CARD16:
http://cgit.freedesktop.org/xorg/lib/libXdmcp/tree/include/X11/Xd
20 matches
Mail list logo
