[PATCH xserver] xf86-video-modesetting: Fix ms_queue_vblank(flags = MS_QUEUE_RELATIVE)

[Alex Goins]

Change 677c32bc refactored all usages of drmWaitVBlank() into a helper function,
ms_queue_vblank().

ms_queue_vblank() takes in an MS_QUEUE_RELATIVE flag to indicate that the
sequence number is relative rather than absolute, but still treats the actual
sequence number as absolute, passing it through ms_crtc_msc_to_kernel_msc()
unconditionally before calling drmWaitVBlank().

ms_crtc_msc_to_kernel_msc() works by subtracting a vblank offset from the
provided sequence number, which only makes sense for absolute sequence numbers.
In the case of PRIME Sync, drmmode_SharedPixmapPrsentOnVBlank() passes in 1,
which results in a large negative vblank offset. After subtracting, we're left
with a relative sequence number of 100,000+, i.e. wait for 100,000+ vblanks...

In the relative case we want to pass in the sequence number unmodified. Simply
add a check to do this.

Signed-off-by: Alex Goins 
---
 hw/xfree86/drivers/modesetting/vblank.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/xfree86/drivers/modesetting/vblank.c 
b/hw/xfree86/drivers/modesetting/vblank.c
index 31cf0bd..fe046e4 100644
--- a/hw/xfree86/drivers/modesetting/vblank.c
+++ b/hw/xfree86/drivers/modesetting/vblank.c
@@ -219,7 +219,8 @@ ms_queue_vblank(xf86CrtcPtr crtc, ms_queue_flag flags,
 if (flags & MS_QUEUE_NEXT_ON_MISS)
 vbl.request.type |= DRM_VBLANK_NEXTONMISS;
 
-vbl.request.sequence = ms_crtc_msc_to_kernel_msc(crtc, msc);
+vbl.request.sequence = (flags & MS_QUEUE_RELATIVE) ?
+msc : ms_crtc_msc_to_kernel_msc(crtc, msc);
 vbl.request.signal = seq;
 ret = drmWaitVBlank(ms->fd, );
 if (ret == 0) {
-- 
2.7.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] Add NonDesktop output property and behaviors.

[Keith Packard]

Giuseppe Bilotta  writes:

> FWIW, some Razer laptop models have a touchpad that doubles as a
> secondary display. Not sure if it's worth mentioning (it does predate
> the Apple Touch Bar, has some very patchy support under Linux, none that
> I know of under Xorg).

Thanks for another example. Is this display driven by the same hardware
as the main display?

> Would it make sense to have a distinct connection status instead? This
> would make it possible to differentiate between actual disconnection and
> “connected, but not really a standard output to be used for desktop”.
> (Would it possible to differentiate otherwise?)

Yes, we could, but the goal is to remain backward compatible with the
existing protocol, and adding a new value here wouldn't meet that
requirement. If the RROutputChangeNotify event wasn't already 32 bytes
long, we could have added a new field there and reported its presence
with an updated version number. Alas.

The obvious alternative would be to report the connected status in a new
output property. I think the presence of all of the other data on the
disconnected output (in particular, a list of modes), along with the
non-desktop property, should be sufficient to know that it is connected?

> For the aforementioned touchpad/display, for example, one could envision
> a “detached” mode where it acts like, say, the Apple Touch Bar, and an
> “attached” mode where it's used like a standard display, for example to
> show a zoomed area around the cursor. Achieving this would require this
> properly to be mutable though.

The current server architecture doesn't provide a mechanism for the user
to override driver-provided values, which pushes against this reasonable
request. It is a policy of sorts, and it's nice to be able to fix things
in user space where necessary. How would you reset it back to 'whatever
the driver thinks' though? Allow it to be set to some other value?

> It would be interesting to make this an enum allowing
> different values, so that clients could differentiate between, say, an
> HMD and a TouchBar. (Maybe instead of RR_PROPERTY_NON_DESKTOP make it a
> RR_PROPERTY_OUTPUT_USAGE and have values 0 for Desktop, 1 for HMD, 2 for
> TouchSomething (could be the Apple thing or the Razer thing)?

We can certainly add more information in additional properties. You do
have access to the EDID data, of course, so you can make choices based
on that. I want to leave the non-desktop property itself a simple
boolean and consider adding more information when we find additional
uses.

> I'm having troubles wrapping my mind around how exactly this works,
> particularly in relation to the root window framebuffer, and about how
> (or rather if) this can be achieved while still granting X clients
> access to the output, even if just in an ‘as needed’ use case (i.e. not
> as part of the “normal” operating mode).

Well, 'connection' status is entirely informative. X applications need
not respect that and can do modesetting even when the output says it's
disconnected. That means that all of the regular X operations are
available. If you wanted to make it part of the regular X desktop, you
would just set a normal mode and it would appear as a normal part of the
desktop.

If you wanted to 'hide' it from other X applications, you would create a
Monitor that covered the geometry of another active output and assign
that to both the other output and the one to be hidden so that the
geometry of the hidden output was not included in the overall Monitor
geometry visible to applications.

> My understanding from the way this is presented is that the output
> properties can be queried as with a traditional output, with the only
> difference that it would claim to be disconnected. So this means in
> particular that this output has a geometry, some size and offset: is the
> offset always zero, even though this doesn't actually relate to the root
> window?

It's an entirely normal output -- the position information would reflect
which portion of the root window was being presented in the 'hidden'
output.

> Could an X client (say, something like Gimp or Krita) actually draw over
> it using the existing X protocol and extensions?

Of course; to the core protocol, it's just more root window
space. However, the window manager will generally confine application
windows to the usable desktop area, so application windows *shouldn't*
ever appear in the hidden space.

> Or should we assume that clients should have specific support for this
> kind of hardware, and therefore only access it via their own specific
> interfaces? In this case, wouldn't it be better to just avoid listing
> the output in RANDR at all?

We need to be able to discover these outputs in applications, and the X
server has special permissions from the kernel to enumerate them. So,
there isn't any other API available to us.

> Making them separate X Screens has a number of advantages:

Yes, except that we don't have 

xorg.0.log repetitive entries

[sawbona]

Hello:

Combing through the xorg.0.log file was an important part of being able to set 
up two Nvidia 
cards (FX580+FX370) to drive three monitors (Dell P1914S + 2x SyncMaster 940N) 
in 
Xinerama mode.

Lots of searching and countless logouts/logins/boots eventually got me the 
working xorg.conf I 
wanted, with 'apparently' no problems: A desktop spanning three 1280*1024 
monitors 
(3840*1024).

This is under PCLinuxOS.
X Protocol Version 11, Revision 0
Build Operating System: Linux_4.13.5-pclos1 PCLinuxOS
Current Operating System: Linux groucho 4.12.10-pclos1

The one thing that caught my eye was how some (quite a few) entries repeat 
themselves 
numerous times within the log file.

For example, these lines accounting for the mode setting of each one of my 
three monitors:

(II) NVIDIA(0): Setting mode "CRT-0:1280x1024"
(II) NVIDIA(1): Setting mode "DFP-0:1280x1024"
(II) NVIDIA(2): Setting mode "CRT-1:1280x1024"

The xorg.0.log file has these three entries repeated nine (9) times each, 
obviously at different 
time stamps.

There are other quite a few parts of the log file that are repeated a number of 
times and seeing 
that there is a 20+ seconds wait from the PW 'enter' to a usable desktop, I am 
starting to 
wonder if there isn't something wrong with the xorg.conf file I put together.

My xorg.0.log has no errors (EE), a coulple of the advisories (WW) that xorg 
calls 'warnings' 
and to which many before me have tried to find answers to (and decided that 
they're harmless) 
so that seems to be all right (?).

So the first question would be if it is 'normal' (as in 'usual') for the log 
file to have repeated 
entries for the exact same thing.

It starts at [ 58.839] and ends at [100.838].

Thanks in advance,
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: [PATCH] Add NonDesktop output property and behaviors.

[Giuseppe Bilotta]

Hello,

> NonDesktop devices are those to which the normal desktop environment
> should not be extended. Examples are Head-mounted displays and the
> Apple Touch Bar.

FWIW, some Razer laptop models have a touchpad that doubles as a
secondary display. Not sure if it's worth mentioning (it does predate
the Apple Touch Bar, has some very patchy support under Linux, none that
I know of under Xorg).

[snip]

> + • A “NonDesktop” output is a device which should not normally be
> +   considered as part of the desktop environment. Head-mounted
> +   displays and the Apple "Touch Bar" are examples of such
> +   devices. A desktop environment should be able to discover which
> +   outputs are connected to such devices and, by default, not present
> +   normal desktop applications on them. This is done by having
> +   RRGetOutputInfo report such devices as Disconnected while reporting
> +   all other information about the device correctly.

Would it make sense to have a distinct connection status instead? This
would make it possible to differentiate between actual disconnection and
“connected, but not really a standard output to be used for desktop”.
(Would it possible to differentiate otherwise?)

> +“NonDesktop” aka RR_PROPERTY_NON_DESKTOP
> + Type:   INTEGER
> + Format: 8
> + Num items:  1
> + Flags   Immutable

For the aforementioned touchpad/display, for example, one could envision
a “detached” mode where it acts like, say, the Apple Touch Bar, and an
“attached” mode where it's used like a standard display, for example to
show a zoomed area around the cursor. Achieving this would require this
properly to be mutable though.

> + Range/List: 0-1

It would be interesting to make this an enum allowing
different values, so that clients could differentiate between, say, an
HMD and a TouchBar. (Maybe instead of RR_PROPERTY_NON_DESKTOP make it a
RR_PROPERTY_OUTPUT_USAGE and have values 0 for Desktop, 1 for HMD, 2 for
TouchSomething (could be the Apple thing or the Razer thing)?

> +
> + Indicates whether the the device attached to this output should not

(double the)   ^   ^

> + be considered part of the normal desktop. When set to 0 or not
> + present, the output should be presented as part of the
> + desktop.
> +
> + When set to 1, the output should not be presented as part of
> + the desktop. To not present an output as part of the desktop,
> + the normal desktop environment should not be shown on this
> + output, nor should desktop applications be positioned on it.
> +
> + When set to 1, RRGetOutputInfo will always report connection status
> + Disconnected, but RROutputChangeNotify events will still be
> + delivered when the connection status changes and all other
> + information about the output and connected device will be
> + reported correctly.

I'm having troubles wrapping my mind around how exactly this works,
particularly in relation to the root window framebuffer, and about how
(or rather if) this can be achieved while still granting X clients
access to the output, even if just in an ‘as needed’ use case (i.e. not
as part of the “normal” operating mode).

My understanding from the way this is presented is that the output
properties can be queried as with a traditional output, with the only
difference that it would claim to be disconnected. So this means in
particular that this output has a geometry, some size and offset: is the
offset always zero, even though this doesn't actually relate to the root
window? Or is the nondesktop output placed in reference to the root
window, but inaccessible? (e.g. with a gap between the “main” root
window and the nondesktop area of the framebufer)?

Could an X client (say, something like Gimp or Krita) actually draw over
it using the existing X protocol and extensions? Or should we assume
that clients should have specific support for this kind of hardware, and
therefore only access it via their own specific interfaces? In this
case, wouldn't it be better to just avoid listing the output in RANDR at
all?

A curious thing about these pieces of hardware is that in some sense
they fit relatively well with the “good old” X Screen concept: they
could be separate X Screens, with the additional caveat that the core
pointer wouldn't be able to move to them, but in the case of hardware
such as the TouchBar or Razer touchpad display, they would still allow
input via the built-in touchscreen interface).

Making them separate X Screens has a number of advantages:

* unless directed otherwise, the vast majority of clients only deal with
  the default X Screen (or the one they were started on);
* you are guaranteed to not get unexpected “bleeds” when a window gets
  repositioned, because the root windows are completely separate from
  each other;
* clients can still access the other X Screens if they really want to.

Re: [PATCH libXau] Avoid out of boundary read access

[Alan Coopersmith]

On 10/19/17 01:18 PM, Tobias Stoeckmann wrote:

If the environment variable HOME is empty, XauFileName triggers an
out of boundary read access (name[1]). If HOME consists of a single
character relative path, the output becomes unexpected, because
"HOME=a" leads to "a.Xauthority" instead of "a/.Xauthority". Granted,
a relative HOME path leads to trouble in general, the code should
properly return "a/.Xauthority" nonetheless.

Signed-off-by: Tobias Stoeckmann 
---
  AuFileName.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/AuFileName.c b/AuFileName.c
index 37c8b62..2946c80 100644
--- a/AuFileName.c
+++ b/AuFileName.c
@@ -85,6 +85,6 @@ XauFileName (void)
bsize = size;
  }
  snprintf (buf, bsize, "%s%s", name,
-  slashDotXauthority + (name[1] == '\0' ? 1 : 0));
+  slashDotXauthority + (name[0] == '/' && name[1] == '\0' ? 1 : 
0));
  return buf;
  }



Reviewed-by: Alan Coopersmith 

--
-Alan Coopersmith-   alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/alanc
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[ANNOUNCE] libXfont 1.5.3

[Matt Turner]

Matt Turner (1):
 libXfont 1.5.3

Michal Srb (2):
 Check for end of string in PatternMatch (CVE-2017-13720)
 pcfGetProperties: Check string boundaries (CVE-2017-13722)

git tag: libXfont-1.5.3

https://xorg.freedesktop.org/archive/individual/lib/libXfont-1.5.3.tar.bz2
MD5:  9ba75bf38ba62a6ad52550ab716da9b3  libXfont-1.5.3.tar.bz2
SHA1: 628b8ca2207f09324b8926084318a2fa2edb16d1  libXfont-1.5.3.tar.bz2
SHA256: ab85c10fd2683481dfef672a77fe60e6a2039558cbc0e9bf56b5e1df471c93d0  
libXfont-1.5.3.tar.bz2
SHA512: 
e7c8a09c4d174129e5d550194d3c3dc2b4abf797e52fe588c6002920727c52cf33b7db8d07fc69c2987e766d3af2d6ddda72f0c70eb21b135c691c97656a81b4
  libXfont-1.5.3.tar.bz2
PGP:  
https://xorg.freedesktop.org/archive/individual/lib/libXfont-1.5.3.tar.bz2.sig

https://xorg.freedesktop.org/archive/individual/lib/libXfont-1.5.3.tar.gz
MD5:  87d1f94e2da66f55a3ec7054008c2501  libXfont-1.5.3.tar.gz
SHA1: 7c306c7fab582d8ac5574aacfc8aa20f4d5aeba1  libXfont-1.5.3.tar.gz
SHA256: e8e3538dacf0a3c0317f0b92a092a3bd9d70fd23de10a6d895435ac78de54b7c  
libXfont-1.5.3.tar.gz
SHA512: 
ad5e576a5ac65c742283de0660c2a084a6819ad450a4eefd74b12ebacbb371b5485ecd78168bb9d263c6c0b87d2c207d6d0a3d3fff176789abae8b280af1a38f
  libXfont-1.5.3.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/lib/libXfont-1.5.3.tar.gz.sig



signature.asc
Description: Digital signature
___
xorg-announce mailing list
xorg-announce@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-announce

[ANNOUNCE] libXfont 1.5.3

[Matt Turner]

Matt Turner (1):
 libXfont 1.5.3

Michal Srb (2):
 Check for end of string in PatternMatch (CVE-2017-13720)
 pcfGetProperties: Check string boundaries (CVE-2017-13722)

git tag: libXfont-1.5.3

https://xorg.freedesktop.org/archive/individual/lib/libXfont-1.5.3.tar.bz2
MD5:  9ba75bf38ba62a6ad52550ab716da9b3  libXfont-1.5.3.tar.bz2
SHA1: 628b8ca2207f09324b8926084318a2fa2edb16d1  libXfont-1.5.3.tar.bz2
SHA256: ab85c10fd2683481dfef672a77fe60e6a2039558cbc0e9bf56b5e1df471c93d0  
libXfont-1.5.3.tar.bz2
SHA512: 
e7c8a09c4d174129e5d550194d3c3dc2b4abf797e52fe588c6002920727c52cf33b7db8d07fc69c2987e766d3af2d6ddda72f0c70eb21b135c691c97656a81b4
  libXfont-1.5.3.tar.bz2
PGP:  
https://xorg.freedesktop.org/archive/individual/lib/libXfont-1.5.3.tar.bz2.sig

https://xorg.freedesktop.org/archive/individual/lib/libXfont-1.5.3.tar.gz
MD5:  87d1f94e2da66f55a3ec7054008c2501  libXfont-1.5.3.tar.gz
SHA1: 7c306c7fab582d8ac5574aacfc8aa20f4d5aeba1  libXfont-1.5.3.tar.gz
SHA256: e8e3538dacf0a3c0317f0b92a092a3bd9d70fd23de10a6d895435ac78de54b7c  
libXfont-1.5.3.tar.gz
SHA512: 
ad5e576a5ac65c742283de0660c2a084a6819ad450a4eefd74b12ebacbb371b5485ecd78168bb9d263c6c0b87d2c207d6d0a3d3fff176789abae8b280af1a38f
  libXfont-1.5.3.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/lib/libXfont-1.5.3.tar.gz.sig



signature.asc
Description: Digital signature
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

[PATCH libXau] Avoid out of boundary read access

[Tobias Stoeckmann]

If the environment variable HOME is empty, XauFileName triggers an
out of boundary read access (name[1]). If HOME consists of a single
character relative path, the output becomes unexpected, because
"HOME=a" leads to "a.Xauthority" instead of "a/.Xauthority". Granted,
a relative HOME path leads to trouble in general, the code should
properly return "a/.Xauthority" nonetheless.

Signed-off-by: Tobias Stoeckmann 
---
 AuFileName.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/AuFileName.c b/AuFileName.c
index 37c8b62..2946c80 100644
--- a/AuFileName.c
+++ b/AuFileName.c
@@ -85,6 +85,6 @@ XauFileName (void)
bsize = size;
 }
 snprintf (buf, bsize, "%s%s", name,
-  slashDotXauthority + (name[1] == '\0' ? 1 : 0));
+  slashDotXauthority + (name[0] == '/' && name[1] == '\0' ? 1 : 
0));
 return buf;
 }
-- 
2.14.2

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[Bug 102643] xf86-video-ati 7.10.0 with EXA acceleration GDM corruption unable to log into GNOME session

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102643

--- Comment #16 from lei.p...@gmail.com ---
(In reply to Michel Dänzer from comment #15)
> I finally got a chance to reproduce and look into this.
> https://patchwork.freedesktop.org/patch/183771/ fixes it for me.

This solves the problem, I've patched 7.10.0 version and it works fine with EXA
acceleration and it detects resolutions properly, can be marked as solved as
far as I'm concerned, thanks.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[PATCH] Add NonDesktop output property and behaviors.

[Keith Packard]

NonDesktop 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 NonDesktop is not part of this
proposal; it is expected that the underlying operating system will
provide this information and have it reflected to X applications
through this extension.

Signed-off-by: Keith Packard 
---
 randrproto.txt | 84 +++---
 1 file changed, 81 insertions(+), 3 deletions(-)

diff --git a/randrproto.txt b/randrproto.txt
index 7312e0b..e717a60 100644
--- a/randrproto.txt
+++ b/randrproto.txt
@@ -186,14 +186,23 @@ from the CRTCs. The Monitor marked as Primary will be 
listed first.
 
 1.6. Introduction to version 1.6 of the extension
 
-Version 1.6 adds resource leasing.
+Version 1.6 adds resource leasing and non desktop output management.
 
- • A 'Lease' is a collection of crtcs and outputs which are made
+ • A “Lease” is a collection of crtcs and outputs which are made
available to a client for direct access via kernel KMS and DRM
APIs. This is done by passing a suitable file descriptor back to
the client which has access to those resources. While leased, those
resources aren't used by the X server.
 
+ • A “NonDesktop” output is a device which should not normally be
+   considered as part of the desktop environment. Head-mounted
+   displays and the Apple "Touch Bar" are examples of such
+   devices. A desktop environment should be able to discover which
+   outputs are connected to such devices and, by default, not present
+   normal desktop applications on them. This is done by having
+   RRGetOutputInfo report such devices as Disconnected while reporting
+   all other information about the device correctly.
+
 1.99 Acknowledgments
 
 Our thanks to the contributors to the design found on the xpert mailing
@@ -764,6 +773,12 @@ dynamic changes in the display environment.
monitor in some way; for fixed-pixel devices, this would generally
indicate which modes match the resolution of the output device.
 
+   Changes in version 1.6 of the protocol:
+
+   When a “NonDesktop” device is connected, the 'connection'
+   field will report Disconnected but the remaining fields will
+   report information about the connected device.
+
 ┌───
 RRListOutputProperties
output:OUTPUT
@@ -775,6 +790,12 @@ dynamic changes in the display environment.
This request returns the atoms of properties currently defined on
the output.
 
+   Changes in version 1.6 of the protocol:
+
+   When a “NonDesktop” device is connected, the property list
+   will be correct for the device, even though RRGetOutputInfo
+   reports the device as disconnected
+
 ┌───
 RRQueryOutputProperty
output: OUTPUT
@@ -806,6 +827,12 @@ dynamic changes in the display environment.
changed by clients. Immutable properties are interpreted by the X
server.
 
+   Changes in version 1.6 of the protocol:
+
+   When a “NonDesktop” device is connected, the property information
+   will be correct for the device, even though RRGetOutputInfo
+   reports the device as disconnected
+
 ┌───
 RRConfigureOutputProperty
output: OUTPUT
@@ -924,6 +951,12 @@ dynamic changes in the display environment.
is True and the bytes-after is zero, the property is also deleted
from the output, and a RROutputPropertyNotify event is generated.
 
+   Changes in version 1.6 of the protocol:
+
+   When a “NonDesktop” device is connected, the property value
+   will be correct for the device, even though RRGetOutputInfo
+   reports the device as disconnected
+
 ┌───
 RRCreateMode
window: WINDOW
@@ -1816,6 +1849,12 @@ factors, such as re-cabling a monitor, etc.
precise change can be detected by examining the new state of the
system.
 
+   Changes in version 1.6 of the protocol:
+
+   When a “NonDesktop” device is connected, this event will be
+   delivered when the connection status of the output changes,
+   however the 'connection' value will be set to 'Disconnected'.
+
 ┌───
 RROutputPropertyNotify:
window: WINDOW  window requesting notification
@@ -1955,6 +1994,13 @@ as long as the semantics are not altered.  Clients 
SHOULD fall back
 gracefully to lower version functionality, though, if the driver
 doesn't handle a mandatory property correctly.
 
+Changes in version 1.6 of the protocol:
+
+When a “NonDesktop” device is connected, the property information
+will be correct for the device, even though RRGetOutputInfo
+reports the device as disconnected. The “NonDesktop” property will be
+set to 1 for such devices and not present on other devices.
+
 9.1 Known properties
 
 "Backlight"aka RR_PROPERTY_BACKLIGHT
@@ -2055,6 +2101,29 @@ doesn't 

[Bug 102643] xf86-video-ati 7.10.0 with EXA acceleration GDM corruption unable to log into GNOME session

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102643

--- Comment #15 from Michel Dänzer  ---
I finally got a chance to reproduce and look into this.
https://patchwork.freedesktop.org/patch/183771/ fixes it for me.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

3 monitors with prime - weird behaviour

[Eduardo Suarez]

I have a three monitor setup with both an intel integrated card and an nvidia
card. I have set the intel card inactive in xorg.conf, so I get an unique x11
display (using prime I think).

However, I get this weird behaviour. On my desired xrandr setup I can render
every monitor right, but I cannot move the mouse to the intel monitor. Playing
around with xrandr I get a setup where mouse can enter the intel monitor, but
then I get some panning on the other monitors that I cannot fix because the
server/xrandr ignores my input pannning values.

Using nvidia proprietary drivers. I appreciate any help.

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s