Re: Proposed X server 1.19 schedule

Keith Packard writes: > [ Unknown signature status ] > > Following the 'release early and often' mantra, we should probably get > 1.19 out the door and let people start using the new code. > > I'd like to propose that we figure out what remaining non-bug changes > we'd like to

[PATCH xserver] config/dbus: Initialize dbus fd to -1 so teardown doesn't use fd 0

The dbus teardown code is called when the server fatal errors even if that is before dbus has ever been initialized. By statically initializing the value of bus_info.fd, we avoid calling RemoveNotifyFd on stdin. Signed-off-by: Keith Packard --- config/dbus-core.c | 2 +- 1

Re: [PATCH vmmouse] conf: rename to 70-vmmouse.conf

On Mon, Jun 13, 2016 at 03:31:13PM +1000, Peter Hutterer wrote: > On Fri, Jun 10, 2016 at 04:32:19PM +0200, Stefan Dirsch wrote: > > Bump up the vmmouse driver to 70, so it get's preferred over libinput, which > > was dropped down to 60. This is only relevant for older kernels, which do > > not >

[Bug 97810] Boot Kernel Panic RX460 (polaris11)

https://bugs.freedesktop.org/show_bug.cgi?id=97810 --- Comment #1 from Alexis --- CPU : AMD A10 7800 GPU : Gigabyte Radeon RX 460 WindForce OC - 2 Gb Motherboard : GA-F2A78M-HD2 8 Gb RAM DDR3 -- You are receiving this mail because: You are the assignee for the

[Bug 97810] New: Boot Kernel Panic RX460 (polaris11)

https://bugs.freedesktop.org/show_bug.cgi?id=97810 Bug ID: 97810 Summary: Boot Kernel Panic RX460 (polaris11) Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW

Re: [PATCH xserver v2] xfree86: recognize primary BUS_PCI device in xf86IsPrimaryPlatform()

On 09/07/16 17:15, Hans de Goede wrote: > Hi, > > On 07-09-16 15:08, Laszlo Ersek wrote: >> The new platform bus code and the old PCI bus code overlap. Platform bus >> can handle any type of device, including PCI devices, whereas the PCI >> code >> can only handle PCI devices. Some drivers only

Re: damage.c wrapping bug?

On Wed, 2016-09-14 at 14:01 -0400, Stirling Westrup wrote: > I'm currently reading through the source for the damage extension in > damage.c and I noticed that the list of functions that get wrapped > when a screen gets damage support is not the same as the list of > functions that get unwrapped

damage.c wrapping bug?

I'm currently reading through the source for the damage extension in damage.c and I noticed that the list of functions that get wrapped when a screen gets damage support is not the same as the list of functions that get unwrapped when the screen is closed. That is DamageSetup() wraps these

Re: [PATCH xserver] modesetting: allow switching from software to hardware cursors.

Hi, On 14-09-16 15:53, Michael Thayer wrote: On 14.09.2016 12:07, Hans de Goede wrote: Hi, On 13-09-16 17:42, Michael Thayer wrote: Currently if modesetting ever fails to set a hardware cursor it will switch to using a software cursor and never go back. Change this to try a hardware cursor

[PATCH xserver v3] xwayland: handle EAGAIN on Wayland fd

wl_display_flush() can fail with EAGAIN and Xwayland would make this a fatal error. When this happens, it means that Xwayland has flooded the Wayland file descriptor, either because the Wayland compositor cannot cope or more likely because of a deadlock situation where the Wayland compositor is

Re: RandR 1.5 Monitors: "No monitor named '...'"

On 09/11/2016 08:29 PM, Nathan Schulte wrote: > I'm using X.org w/ Debian Sid: > >> nmschulte@desmas-l:~$ Xorg -version >> >> X.Org X Server 1.18.4 >> Release Date: 2016-07-19 >> X Protocol Version 11, Revision 0 >> Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian >> Current Operating

Xlib doc

Hello, XRestackWindows function : It is said in https://www.x.org/releases/X11R7.7/doc/libX11/libX11/libX11.html#Changing_Window_Stacking_Order : "For each window in the window array that is not a child of the specified window, a BadMatch error results." but in

Re: [PATCH xserver] modesetting: allow switching from software to hardware cursors.

On 14.09.2016 12:07, Hans de Goede wrote: Hi, On 13-09-16 17:42, Michael Thayer wrote: Currently if modesetting ever fails to set a hardware cursor it will switch to using a software cursor and never go back. Change this to try a hardware cursor first every time a new one is set. This is

Fwd: [PATCH v2 xserver] xkb: fix turbo-repeat of RedirectKey-ed keysyms

Hi, Here's the notes from Mihail, which I'd accidentally dropped whilst passing this on. Cheers, Daniel -- Forwarded message -- From: Mihail Konev Date: 14 September 2016 at 07:45 Subject: [PATCH v2 xserver] xkb: fix turbo-repeat of RedirectKey-ed keysyms To:

Re: [PATCH] xkb: fix turbo-repeat of RedirectKey-ed keysyms

Hi, On 14 September 2016 at 11:47, Daniel Stone wrote: > RedirectKey() action had been broken by commit 2e6190. > A dropped check caused over-intense autorepeat of keysyms enriched > with the action. > > Previous to this commit, the check wrapped the entire switch() block,

[PATCH] xkb: fix turbo-repeat of RedirectKey-ed keysyms

From: Mihail Konev RedirectKey() action had been broken by commit 2e6190. A dropped check caused over-intense autorepeat of keysyms enriched with the action. Previous to this commit, the check wrapped the entire switch() block, which was dropped with the move to a separate

Re: [PATCH xserver] modesetting: allow switching from software to hardware cursors.

Hi, On 13-09-16 17:42, Michael Thayer wrote: Currently if modesetting ever fails to set a hardware cursor it will switch to using a software cursor and never go back. Change this to try a hardware cursor first every time a new one is set. This is needed because hardware may be able to handle

Re: [xserver PULL master] Modesetting driver prime fixes (unreviewed)

Hi, On 13-09-16 17:45, Adam Jackson wrote: On Tue, 2016-09-13 at 12:53 +0200, Hans de Goede wrote: The following changes since commit 35c4e96ed1d372dd161480be8cddcd2d4549e449: randr: Fix crtc_bounds when using rotation combined with reflection (2016-09-13 10:27:30 +0200) are available

[Bug 97578] Radeon HD 5450 suddenly blanks screen or shows old content

https://bugs.freedesktop.org/show_bug.cgi?id=97578 --- Comment #17 from Michel Dänzer --- (In reply to Markus Näher from comment #15) > Well ... I asked about xorg.conf.d because there is no xorg.conf on my PC's. > As far as I understand, this means my X server is

[Bug 90910] Switching workspaces in AwesomeWM - workspace changes but Awesome lags behind

https://bugs.freedesktop.org/show_bug.cgi?id=90910 --- Comment #2 from Paul Menzel --- Do you also experience the problem, when maximizing a Firefox window on a screen with several Firefox windows, and when demaximizing it, the background is not updated? -- You are

[Bug 97578] Radeon HD 5450 suddenly blanks screen or shows old content

https://bugs.freedesktop.org/show_bug.cgi?id=97578 --- Comment #16 from Markus Näher --- Created attachment 126510 --> https://bugs.freedesktop.org/attachment.cgi?id=126510=edit XFCE compositor settings -- You are receiving this mail because: You are the assignee for

[Bug 97578] Radeon HD 5450 suddenly blanks screen or shows old content

https://bugs.freedesktop.org/show_bug.cgi?id=97578 --- Comment #14 from Michel Dänzer --- (In reply to Markus Näher from comment #13) > How do I set it in xorg.conf.d ? You don't. :) xorg.conf.d is for system configuration snippets, users should always use /etc/X11/xorg.conf

Re: weird Xwayland and compositor deadlock issue [WAS: [PATCH xserver v2] xwayland: handle EAGAIN and EINTR gracefully]

On Tue, 13 Sep 2016 12:04:14 -0400 (EDT) Olivier Fourdan wrote: > Hi Pekka, > > - Original Message - > > Hi Olivier, > > > > I don't have any solution for you. The interactions between the Wayland > > compositor and Xwayland are known to be very easily deadlockable

[Bug 91922] [SUMO] Xorg Server crash on launch 3D application using DRI_PRIME, if GLAMOR is used as AccelMethod with radeon driver

https://bugs.freedesktop.org/show_bug.cgi?id=91922 Michel Dänzer changed: What|Removed |Added Resolution|--- |FIXED

Re: [PATCH xserver] config: fix GPUDevice fail when AutoAddGPU off + BusID

On 08/09/16 10:24 PM, Qiang Yu wrote: > This fix is for the following xorg.conf can work: > > Section "ServerFlags" > Option "AutoAddGPU" "off" > EndSection > > Section "Device" > Identifier "Amd" > Driver "ati" > BusID "PCI:1:0:0" > EndSection > > Section