[PATCH xserver 2/4] xfree86: Disable cursor whenever turning off CRTC during modeset

This makes sure the CRTC's cursor is hidden before we hand the CRTC over to some other application. Signed-off-by: Keith Packard Reviewed-by: Michel Dänzer Reviewed-by: Alex Deucher --- hw/xfree86/modes/xf86Crtc.c| 16

[PATCH xserver 3/4] xf86-video-modesetting: Create CONNECTOR_ID properties for outputs

This lets a DRM client map between X outputs and kernel connectors. Signed-off-by: Keith Packard --- hw/xfree86/drivers/modesetting/drmmode_display.c | 24 1 file changed, 24 insertions(+) diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c

[PATCH xserver 1/4] xf86-video-modesetting: Support new vblank kernel API [v2]

drmCrtcGetSequence returns the current vblank sequence and time. drmCrtcQueueSequence queues an event for delivery at a specified vblank sequence. Use these (when available) in preference to drmWaitVBlank. v2: Remove FIRST_PIXEL_OUT_FLAG. This has been removed from the kernel API.

[PATCH xserver 4/4] Add RandR leases with modesetting driver support [v3]

This adds support for RandR CRTC/Output leases through the modesetting driver, creating a lease using new kernel infrastructure and returning that to a client through an fd which will have access to only those resources. v2: When a lease terminates for a crtc we have saved data for, go

[PATCH xserver 0/4] Add RandR 1.6 lease support

This is an updated version of this series, rebased on current master and including v3 of the main patch. That final patch has a description of the changes from v2, but the main thing is a lot of changes needed to keep the server from doing anything with the leased objects or including them in any

Re: [PATCH xserver] xf86-video-modesetting: Update all property values at uevent time

Keith Packard writes: > We were updating the link-status property when a uevent came in, but > we also want to update the non-desktop property, and potentially > others as well. This patch just updates every property provided by the > kernel, sending changes to DIX so it can

[PATCH xserver 1/5] xf86-video-modesetting: Update property values at detect and uevent time

We were updating the link-status property when a uevent came in, but we also want to update the non-desktop property, and potentially others as well. We also want to check at detect time in case we don't get a hotplug event. This patch updates every property provided by the kernel, sending

[PATCH xserver 3/5] xf86-video-modesetting: Record non-desktop kernel property at PreInit time

Save any value of the kernel non-desktop property in the xf86Output structure to avoid non-desktop outputs in the default configuration. Signed-off-by: Keith Packard --- hw/xfree86/drivers/modesetting/drmmode_display.c | 6 ++ 1 file changed, 6 insertions(+) diff --git

[PATCH xserver 0/5] Add support for non-desktop output property

Non-desktop monitors are described in RandR protocol version 1.6 to be those which "shouldn't" normally be part of a desktop environment. Monitors like head-mounted displays or the Apple Touch Bar. Linux detects these using EDID quirks and sets a connector property. We reflect that property up to

[PATCH xserver 5/5] randr: Support "non-desktop" property

Tracks changes to the non-desktop property so that when non-zero, outputs will always appear to be disconnected. Signed-off-by: Keith Packard --- randr/randrstr.h | 3 +++ randr/rroutput.c | 26 +- randr/rrproperty.c | 27

[PATCH xserver 2/5] xfree86/modes: Check for non-desktop monitors during PreInit

At startup, we want to ignore non-desktop monitors unless we don't find any desktop monitors. Because there are no DIX RandR resources allocated, let the driver store this information in a new field in the xf86Output structure and then use that value to help decide whether to include an output as

[PATCH xserver 4/5] randr: Declare incoming property values const

RRChangeOutputProperty and RRConfigureOutputProperty should not modify their parameters, and callers may want to pass pointers to fixed data, so declare the value pointers as const in both cases. Signed-off-by: Keith Packard --- randr/randrstr.h | 4 ++-- randr/rrproperty.c

Re: [RFC PATCH xserver] os: move tempfiles.d/x11.conf from systemd to here

On Thu, Nov 30, 2017 at 12:22:46PM +, Emil Velikov wrote: > Hi Peter, > > On 9 November 2017 at 04:19, Peter Hutterer wrote: > > Let's not rely on some other package to set up and clean up after our > > tempfiles. > > > > Signed-off-by: Peter Hutterer

[PATCH xserver] xf86-video-modesetting: Update all property values at uevent time

We were updating the link-status property when a uevent came in, but we also want to update the non-desktop property, and potentially others as well. This patch just updates every property provided by the kernel, sending changes to DIX so it can track things as well. Signed-off-by: Keith Packard

[PATCH randrproto 1/2] Add Leases. [v2]

A "lease" is a set of crtc and output resources granted to another application for use outside of X. These will not be usable through the X protocol until the lease terminates. Leased outputs will be seen as disconnected, leased CRTCs will be seen as not usable with any output. v2: Delete

[PATCH randrproto 0/2] Leases and non-desktop for RandR protocol

Here's a two patch series which adds leases and support for 'non-desktop' outputs. Leases are a way to take a set of X server resources and give them over to another application for a while. The X server implementation for this uses Linux changes already heading upstream. non-desktop outputs

[PATCH randrproto 2/2] Add non-desktop output property and behaviors [v3]

non-desktop devices are those to which the normal desktop environment should not be extended. Examples are Head-mounted displays and the Apple Touch Bar. How an output device is set to non-desktop is not part of this proposal; it is expected that the underlying operating system will provide this

Re: X is consuming ~100 GiB of RAM(!)

> It's been uncommon to have such a configuration AFAIK, frankly I was a little surprised to see someone mentioning some modern G200 use case. Supermicro servers uses the Nuvoton WPCM450 BMC and it is off of that where the Matrox G200eW resides (for the console/video output/display). (The manual

Fwd: X is consuming ~100 GiB of RAM(!)

-- Forwarded message -- From: Hi-Angel Date: 7 December 2017 at 21:12 Subject: Re: X is consuming ~100 GiB of RAM(!) To: Ewen Chan On 7 December 2017 at 19:22, Ewen Chan wrote: >> That's one more of beauties of

Re: X is consuming ~100 GiB of RAM(!)

On Thu, Dec 07, 2017 at 11:22:30AM -0500, Ewen Chan wrote: > Hi-Angel: > > > Yes, now it should be using CPU for rendering. > > Hmmm...I am not so sure if that was really what I want. > > It just reminds me of the adage of where you fix a leak/problem at one > part/section of a pipe, but then

Re: X is consuming ~100 GiB of RAM(!)

Ewen Chan composed on 2017-12-07 11:22 (UTC-0500):... > My early subjective analysis (with this mgag200 blacklist) puts the time it > takes to run the simulations now on par with Windows and Windows just > worked (properly) like this from the get go. > People keep talking about great and

Re: X is consuming ~100 GiB of RAM(!)

Hi-Angel: > Yes, now it should be using CPU for rendering. Hmmm...I am not so sure if that was really what I want. It just reminds me of the adage of where you fix a leak/problem at one part/section of a pipe, but then create another one problem somewhere else down the pipe. > That's one more

Re: Merged repo for protocol headers? Why are they split?

On 6 December 2017 at 12:37, Daniel Martin wrote: > Hi all, > > if anyone would like to have a look, I've pushed my current work on > the merged proto repo here: > https://github.com/bartsch/xorg-proto2k/ > It's generated as is with: >

Re: X is consuming ~100 GiB of RAM(!)

Yes, now it should be using CPU for rendering. If you're eager to save some cycles, you could recompile both Xorg and Mesa with optimizations "-flto=2 -march=native -O3 -pipe -fno-stack-protector -fno-semantic-interposition -fmerge-all-constants". That's one more of beauties of open source :) That

Re: X is consuming ~100 GiB of RAM(!)

Hi-Angel: I'm just asking due to innate curiosity. But the other part of it is I am wondering if the other driver is using CPU cycles to draw/render the display/(raster?). I am asking because in the analyis runs, they are taking longer to run than they were before I blacklisted the mgag200

Re: X is consuming ~100 GiB of RAM(!)

Yeah, nice, it worked. As for what other driver in the output should accord to vesa or whatever that provides the basic functional of outputting to a monitor — sorry, I don't know, I hope somebody else here can tell it. I don't think it's important for our purposes though. On 7 December 2017 at

Re: X is consuming ~100 GiB of RAM(!)

P.S. I'm neither a dev nor all that familiar with this stuff either. I'm just a user. And I've been on the SuSE forums talking with those people in trying to figure out this issue that I am seeing where Xorg was consuming ~100 GiB of RAM which, pretty much every technical person I've talked to

Re: X is consuming ~100 GiB of RAM(!)

Felix: I might be able to try that. It'll probably be the better part of a week before I will get around to testing that (only because my analysis script need to load the system significantly enough in order to trigger this issue). In regards to your question at the end, someone else who is

Re: X is consuming ~100 GiB of RAM(!)

Hi-Angel: > Have you rebuild initramfs after blacklisting by the way? So...I did what that thread (and the thread that it points to within that thread) says to do. Created blacklist.conf and then put in there: blacklist mgag200 and then I ran dracut --regenerate-all --force and rebooted (per

[Bug 33183] mouse cursor turns into thin vertical dashed line

https://bugs.freedesktop.org/show_bug.cgi?id=33183 --- Comment #50 from Michel Dänzer --- (In reply to H Zeng from comment #49) > When I was about to select texts in Konsole, suddenly the window did not > respond to my mouse click. Then I found the mouse cursor was stalked as

Re: X is consuming ~100 GiB of RAM(!)

[ Dropping x...@freedesktop.org from Cc, one copy of each list post is enough :) ] On 2017-12-07 05:39 AM, Hi-Angel wrote: > > You know, btw, another silly idea: if blacklisting the driver will > help, but you actually care of graphics performance — you could try > enabling it back, and then

Re: [PATCH xserver] os: Fix strtok/free crash in ComputeLocalClient

Am 06.12.2017 12:16, schrieb Tomasz Śniatowski: > Don't reuse cmd for strtok output to ensure the proper pointer is > freed afterwards. > > The code incorrectly assumed the pointer returned by strtok(cmd, ":") > would always point to cmd. However, strtok(str, sep) != str if str > begins with

[PATCH] XFixes: Fix cursor reference when calling, XFixesGetCursorImage or XFixesGetCursorImageAndName.

[NOTE] This should be nominated for previous branches too! These two calls save a pointer to the current cursor during DisplayCursor(), but the cursor can be destroyed leaving a dangling reference. This patch wraps this using the cursor reference counters to ensure the cursor isn't deleted during

Re: Merged repo for protocol headers? Why are they split?

On 6 December 2017 at 16:23, Gioele Barabucci wrote: > Hi, > > 06.12.2017 13:37 Daniel Martin: >> >> PS: Just talked to Peter, he's okay with filter-branch as it gives us >> git-log without a struggle and references to other commits can be >> looked up in the old repos > > A

Re: [PATCH] XFixes: Fix cursor reference when calling, XFixesGetCursorImage or XFixesGetCursorImageAndName.

[v2] These two calls save a pointer to the current cursor during DisplayCursor(), but the cursor can be destroyed leaving a dangling reference. This patch wraps this using the cursor reference counters to ensure the cursor isn't deleted during it's use. This bug was fixed in RedHat's bugzilla

[PATCH xserver] os: Fix strtok/free crash in ComputeLocalClient

Don't reuse cmd for strtok output to ensure the proper pointer is freed afterwards. The code incorrectly assumed the pointer returned by strtok(cmd, ":") would always point to cmd. However, strtok(str, sep) != str if str begins with sep. This caused an invalid-free crash when running a program