Re: Xvfb concerns and dummy driver issues

Is the plan to keep Xvfb as-is (KDrive?) or to move it to a wrapper around Xorg+Dummy? Any ideas about why the dummy driver was not working (killing the headless dummy X server brings down any X server running on hardware, like the dummy X server somehow gets entangled with other X servers on the

Re: triple head: xrandr commands ignored

On 29/04/17 04:15 AM, Alex Deucher wrote: > On Fri, Apr 28, 2017 at 5:46 AM, Felix Miata wrote: >> Felix Miata composed on 2017-04-28 05:22 (UTC-0400): >> >>> Felix Miata composed on 2017-04-27 06:35 (UTC-0400): >> openSUSE Tumbleweed kernel 4.10.10 server

Re: triple head: xrandr commands ignored

Alex Deucher composed on 2017-04-28 15:15 (UTC-0400): > Felix Miata wrote: > All evergreen cards only have 2 PLLs so that means they can only > support two independent clocks. If you want to use more than two > displays, you'll need to use displayport or for non-displayport, at > least two of

Re: Proposal for RandR version 1.6, Leases [v2]

Keith Packard writes: With the changes to the kernel interface, and discussion about how to mask HMD outputs from X applications still ongoing, I've ripped the grabs out of the protocol and will add whatever we come up with back at some point. In any case, there are just two

Re: triple head: xrandr commands ignored

On Fri, Apr 28, 2017 at 5:46 AM, Felix Miata wrote: > Felix Miata composed on 2017-04-28 05:22 (UTC-0400): > >> Felix Miata composed on 2017-04-27 06:35 (UTC-0400): > >>> openSUSE Tumbleweed >>> kernel 4.10.10 >>> server 1.19.3 >>> ATI HD5450 PCIe gfxcard (Cedar) > ... >

Re: [PATCH xserver] Makefile.am: add the meson files to the tarball

Eric Anholt writes: > Matching sucks because it might pick up other things, but it's the only > reasonable solution when using autotool's make dist. Hopefully we can > stop that soon. The alternative would be to edit every Makefile.am to include the associated meson files. I'm

[PATCH xserver 2/2] meson: Fix glx build with DRI2 disabled.

A common meson pattern is to use empty arrays for optional sources and dependencies, since it generally iterates over trees of arrays looking for values. A value of '' will actually go looking for ''. Signed-off-by: Eric Anholt --- glx/meson.build | 2 +- 1 file changed, 1

Re: [PATCH xserver] Makefile.am: add the meson files to the tarball

Peter Hutterer writes: > I'll send a patch out that tightens the glob to just meson.build and add > the extra config.h.meson.in manually in the list of files, that should > make it more obvious and less error-prone, so everyone is happy (fsvo > happy ;) Yeah, happy

Re: [PATCH xserver] Makefile.am: add the meson files to the tarball

Peter Hutterer writes: > While we're providing both build systems, we'll likely have 'make dist' > generated tarballs - those tarballs should be buildable with meson to > have more exposure. > > Signed-off-by: Peter Hutterer > --- > triggered

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

Pekka Paalanen writes: > IMHO, if nothing is providing a picture intended for the HMD, the HMD > should be off. There is no use in showing an arbitrary image that does > not look right, is there? Well, if the HMD is being worn and the application crashes, then what you want

Re: [PATCH xserver] Makefile.am: add the meson files to the tarball

On 29/04/2017 08:06 , Keith Packard wrote: Eric Anholt writes: Matching sucks because it might pick up other things, but it's the only reasonable solution when using autotool's make dist. Hopefully we can stop that soon. The alternative would be to edit every Makefile.am

[PATCH xserver 1/2] meson: use link_with for Xorg's shared modules as well as Xorg.

I converted Xorg when meson 0.40 came out, but fumbled my grep and forgot that I had instances of the .extract_all_objects() workaround in dixmods, too. Signed-off-by: Eric Anholt --- hw/xfree86/dixmods/meson.build | 8 1 file changed, 4 insertions(+), 4 deletions(-)

Re: triple head: xrandr commands ignored

Felix Miata composed on 2017-04-28 05:22 (UTC-0400): > Felix Miata composed on 2017-04-27 06:35 (UTC-0400): >> openSUSE Tumbleweed >> kernel 4.10.10 >> server 1.19.3 >> ATI HD5450 PCIe gfxcard (Cedar) ... When I use this startup script: xrandr --output DVI-0 --primary --mode 1920x1200 --left-of

Re: [PATCH xserver] Makefile.am: add the meson files to the tarball

On Friday, 2017-04-28 16:09:55 +1000, Peter Hutterer wrote: > While we're providing both build systems, we'll likely have 'make dist' > generated tarballs - those tarballs should be buildable with meson to > have more exposure. > > Signed-off-by: Peter Hutterer > --- >

Re: [PATCH xserver 4/9] meson: Build libglx.so

On 27/04/2017 18:55, Adam Jackson wrote: Signed-off-by: Adam Jackson --- glx/meson.build| 5 + hw/xfree86/dixmods/meson.build | 15 +++ meson.build| 2 ++ 3 files changed, 22 insertions(+) diff --git a/glx/meson.build

Re: [PATCH xserver] Makefile.am: add the meson files to the tarball

On Friday, 2017-04-28 11:30:08 +0100, Eric Engestrom wrote: > On Friday, 2017-04-28 16:09:55 +1000, Peter Hutterer wrote: > > While we're providing both build systems, we'll likely have 'make dist' > > generated tarballs - those tarballs should be buildable with meson to > > have more exposure. >

Re: [PATCH xserver] Makefile.am: add the meson files to the tarball

> Date: Fri, 28 Apr 2017 16:09:55 +1000 > From: Peter Hutterer > > While we're providing both build systems, we'll likely have 'make dist' > generated tarballs - those tarballs should be buildable with meson to > have more exposure. > > Signed-off-by: Peter Hutterer

[PATCH xserver] Makefile.am: add the meson files to the tarball

While we're providing both build systems, we'll likely have 'make dist' generated tarballs - those tarballs should be buildable with meson to have more exposure. Signed-off-by: Peter Hutterer --- triggered by:

Re: triple head: xrandr commands ignored

Felix Miata composed on 2017-04-27 06:35 (UTC-0400): > openSUSE Tumbleweed > kernel 4.10.10 > server 1.19.3 > ATI HD5450 PCIe gfxcard (Cedar) > During BIOS display, 1920x1080 Dell is blank, the other two in 80x25. When KMS > kicks in the framebuffers sometimes only two of the three light up, and