| 2009-01-12 20:48:01 |
Bryce Harrington |
bug |
|
|
added bug |
| 2009-01-12 20:52:51 |
Bryce Harrington |
xorg: status |
New |
In Progress |
|
| 2009-01-12 20:52:51 |
Bryce Harrington |
xorg: importance |
Undecided |
Wishlist |
|
| 2009-01-12 20:52:51 |
Bryce Harrington |
xorg: statusexplanation |
|
|
|
| 2009-01-12 20:58:56 |
Bryce Harrington |
description |
Binary package hint: xorg
[Problem]
X does not support (or does not support very well) displaying a desktop across more than one video card. When it is possible, a variety of bugs are experienced.
[Discussion]
Prior to the introduction of Xrandr it was (sometimes) possible to configure xorg.conf to display on multiple video cards. One could then use Xinerama, etc. to stitch screens into a contiguous desktop. Of course, any alterations to this setup usually required hand-tuning xorg.conf.
The introduction of Xrandr made a number of things much easier, however it is not good at handling the case of multiple video cards. It can handle dual-head displays, where both monitors are connected to separate outputs on the same video card, but does not work as well with outputs on two different cards.
The fundamental problem (as I understand it) is essentially that X can talk to only one physical "pool" of memory, and each card has its own physical pool. Recent developments including GEM and several kernel changes promise to remedy this by enabling these pools to be aggregated and managed as a single virtual pool.
[Exceptions]
As mentioned above, the problem is most notable with drivers that have switched from Xinerama to Xrandr. If you're using an older driver that still uses the old Xinerama approach, you *might* find it works acceptably.
In my own testing, I've found cases where I could get displays across multiple cards, but I ran into so many different bugs (mouse not working properly, X crashing, display corruption, etc.) that it was essentially unusable. Resolving those issues will likely wait until the aforementioned architecture is fully in place. |
Binary package hint: xorg
[Problem]
X does not support (or does not support very well) displaying a desktop across more than one video card. When it is possible, a variety of bugs are experienced.
[Discussion]
Prior to the introduction of Xrandr it was (sometimes) possible to configure xorg.conf to display on multiple video cards. One could then use Xinerama, etc. to stitch screens into a contiguous desktop. Of course, any alterations to this setup usually required hand-tuning xorg.conf.
The introduction of Xrandr made a number of things much easier, however it is not good at handling the case of multiple video cards. It can handle dual-head displays, where both monitors are connected to separate outputs on the same video card, but does not work as well with outputs on two different cards.
The fundamental problem (as I understand it) is essentially that X can talk to only one physical "pool" of memory, and each card has its own physical pool. Recent developments including GEM and several kernel changes promise to remedy this by enabling these pools to be aggregated and managed as a single virtual pool.
[Exceptions]
As mentioned above, the problem is most notable with drivers that have switched from Xinerama to Xrandr. If you're using an older driver that still uses the old Xinerama approach, you *might* find it works acceptably.
In my own testing, I've found cases where I could get displays across multiple cards (separate screens per-card) when running xrandr, but I ran into so many different bugs (mouse not working properly, X crashing, display corruption, etc.) that it was essentially unusable. Resolving those issues will likely wait until the aforementioned architecture is fully in place. |
|
| 2009-01-12 21:17:25 |
Bryce Harrington |
description |
Binary package hint: xorg
[Problem]
X does not support (or does not support very well) displaying a desktop across more than one video card. When it is possible, a variety of bugs are experienced.
[Discussion]
Prior to the introduction of Xrandr it was (sometimes) possible to configure xorg.conf to display on multiple video cards. One could then use Xinerama, etc. to stitch screens into a contiguous desktop. Of course, any alterations to this setup usually required hand-tuning xorg.conf.
The introduction of Xrandr made a number of things much easier, however it is not good at handling the case of multiple video cards. It can handle dual-head displays, where both monitors are connected to separate outputs on the same video card, but does not work as well with outputs on two different cards.
The fundamental problem (as I understand it) is essentially that X can talk to only one physical "pool" of memory, and each card has its own physical pool. Recent developments including GEM and several kernel changes promise to remedy this by enabling these pools to be aggregated and managed as a single virtual pool.
[Exceptions]
As mentioned above, the problem is most notable with drivers that have switched from Xinerama to Xrandr. If you're using an older driver that still uses the old Xinerama approach, you *might* find it works acceptably.
In my own testing, I've found cases where I could get displays across multiple cards (separate screens per-card) when running xrandr, but I ran into so many different bugs (mouse not working properly, X crashing, display corruption, etc.) that it was essentially unusable. Resolving those issues will likely wait until the aforementioned architecture is fully in place. |
Binary package hint: xorg
[Problem]
X does not support (or does not support very well) displaying a desktop across more than one video card. When it is possible, a variety of bugs are experienced.
[Discussion]
Prior to the introduction of Xrandr it was (sometimes) possible to configure xorg.conf to display on multiple video cards. One could then use Xinerama, etc. to stitch screens into a contiguous desktop. Of course, any alterations to this setup usually required hand-tuning xorg.conf.
The introduction of Xrandr made a number of things much easier, however it is not good at handling the case of multiple video cards. It can handle dual-head displays, where both monitors are connected to separate outputs on the same video card, but does not work as well with outputs on two different cards.
The fundamental problem (as I understand it) is essentially that X can talk to only one physical "pool" of memory, and each card has its own physical pool. Recent developments including GEM and several kernel changes promise to remedy this by enabling these pools to be aggregated and managed as a single virtual pool.
[Exceptions]
As mentioned above, the problem is most notable with drivers that have switched from Xinerama to Xrandr. If you're using an older driver that still uses the old Xinerama approach, you *might* find it works acceptably.
In my own testing, I've found cases where I could get displays across multiple cards (separate screens per-card) when running xrandr, but I ran into so many different bugs (mouse not working properly, X crashing, display corruption, etc.) that it was essentially unusable. Even if it could be made to work, this configuration is quite non-standard and not well tested. Resolving those issues will likely wait until the aforementioned architecture is fully in place. |
|
| 2009-01-12 21:22:34 |
Bryce Harrington |
description |
Binary package hint: xorg
[Problem]
X does not support (or does not support very well) displaying a desktop across more than one video card. When it is possible, a variety of bugs are experienced.
[Discussion]
Prior to the introduction of Xrandr it was (sometimes) possible to configure xorg.conf to display on multiple video cards. One could then use Xinerama, etc. to stitch screens into a contiguous desktop. Of course, any alterations to this setup usually required hand-tuning xorg.conf.
The introduction of Xrandr made a number of things much easier, however it is not good at handling the case of multiple video cards. It can handle dual-head displays, where both monitors are connected to separate outputs on the same video card, but does not work as well with outputs on two different cards.
The fundamental problem (as I understand it) is essentially that X can talk to only one physical "pool" of memory, and each card has its own physical pool. Recent developments including GEM and several kernel changes promise to remedy this by enabling these pools to be aggregated and managed as a single virtual pool.
[Exceptions]
As mentioned above, the problem is most notable with drivers that have switched from Xinerama to Xrandr. If you're using an older driver that still uses the old Xinerama approach, you *might* find it works acceptably.
In my own testing, I've found cases where I could get displays across multiple cards (separate screens per-card) when running xrandr, but I ran into so many different bugs (mouse not working properly, X crashing, display corruption, etc.) that it was essentially unusable. Even if it could be made to work, this configuration is quite non-standard and not well tested. Resolving those issues will likely wait until the aforementioned architecture is fully in place. |
Binary package hint: xorg
[Problem]
X does not support (or does not support very well) displaying a desktop across more than one video card. When it is possible, a variety of bugs are experienced.
[Discussion]
Prior to the introduction of Xrandr it was (sometimes) possible to configure xorg.conf to display on multiple video cards. One could then use Xinerama, etc. to stitch screens into a contiguous desktop. Of course, any alterations to this setup usually required hand-tuning xorg.conf.
The introduction of Xrandr made a number of things much easier, however it is not good at handling the case of multiple video cards. It can handle dual-head displays, where both monitors are connected to separate outputs on the same video card, but does not work as well with outputs on two different cards.
The fundamental problem (as I understand it) is essentially that X can talk to only one physical "pool" of memory, and each card has its own physical pool. Recent developments including GEM and several kernel changes promise to remedy this by enabling these pools to be aggregated and managed as a single virtual pool. Once the X server and drivers are updated to utilize this new architecture, they should be able to support multi-card functionality with Xrandr as well as (and better than) the old Xinerama configuration, including reconfiguring the display without needing to edit xorg.conf or restart X.
[Exceptions]
As mentioned above, the problem is most notable with drivers that have switched from Xinerama to Xrandr. If you're using an older driver that still uses the old Xinerama approach, you *might* find it works acceptably.
In my own testing, I've found cases where I could get displays across multiple cards (separate screens per-card) when running xrandr, but I ran into so many different bugs (mouse not working properly, X crashing, display corruption, etc.) that it was essentially unusable. Even if it could be made to work, this configuration is quite non-standard and not well tested. Resolving those issues will likely wait until the aforementioned architecture is fully in place. |
|
| 2009-01-24 02:09:46 |
Bryce Harrington |
xorg: bugtargetdisplayname |
xorg (Ubuntu) |
xorg-server (Ubuntu) |
|
| 2009-01-24 02:09:46 |
Bryce Harrington |
xorg: bugtargetname |
xorg (Ubuntu) |
xorg-server (Ubuntu) |
|
| 2009-01-24 02:09:46 |
Bryce Harrington |
xorg: title |
Bug #316514 in xorg (Ubuntu): "MASTER: Multiple video cards not supported" |
Bug #316514 in xorg-server (Ubuntu): "MASTER: Multiple video cards not supported" |
|
| 2009-03-07 03:44:36 |
Bryce Harrington |
bug |
|
|
assigned to xorg-server |
| 2009-03-07 04:01:56 |
Bug Watch Updater |
xorg-server: status |
Unknown |
In Progress |
|
| 2009-11-17 19:07:18 |
Ubuntu QA Website |
tags |
|
iso-testing |
|
| 2009-12-05 02:28:44 |
Bryce Harrington |
removed subscriber Bryce Harrington |
|
|
|
| 2010-03-25 01:32:27 |
Bryce Harrington |
bug watch added |
|
http://bugs.freedesktop.org/show_bug.cgi?id=18160 |
|
| 2010-04-08 01:29:05 |
Bryce Harrington |
summary |
MASTER: Multiple video cards not supported |
MASTER: Xinerama/Multihead with several video cards is not supported |
|
| 2010-08-31 01:57:40 |
technomage bruce |
bug |
|
|
added subscriber technomage bruce |
| 2010-09-14 15:04:42 |
Bug Watch Updater |
xorg-server: importance |
Unknown |
Medium |
|
| 2010-10-04 17:45:01 |
Alejandro Cuervo |
bug |
|
|
added subscriber Alejandro Cuervo |
| 2010-11-23 21:13:58 |
Bryce Harrington |
summary |
MASTER: Xinerama/Multihead with several video cards is not supported |
MASTER: Xinerama/Multihead with multiple video cards is not supported for most video drivers |
|
| 2010-11-23 21:15:36 |
Bryce Harrington |
description |
Binary package hint: xorg
[Problem]
X does not support (or does not support very well) displaying a desktop across more than one video card. When it is possible, a variety of bugs are experienced.
[Discussion]
Prior to the introduction of Xrandr it was (sometimes) possible to configure xorg.conf to display on multiple video cards. One could then use Xinerama, etc. to stitch screens into a contiguous desktop. Of course, any alterations to this setup usually required hand-tuning xorg.conf.
The introduction of Xrandr made a number of things much easier, however it is not good at handling the case of multiple video cards. It can handle dual-head displays, where both monitors are connected to separate outputs on the same video card, but does not work as well with outputs on two different cards.
The fundamental problem (as I understand it) is essentially that X can talk to only one physical "pool" of memory, and each card has its own physical pool. Recent developments including GEM and several kernel changes promise to remedy this by enabling these pools to be aggregated and managed as a single virtual pool. Once the X server and drivers are updated to utilize this new architecture, they should be able to support multi-card functionality with Xrandr as well as (and better than) the old Xinerama configuration, including reconfiguring the display without needing to edit xorg.conf or restart X.
[Exceptions]
As mentioned above, the problem is most notable with drivers that have switched from Xinerama to Xrandr. If you're using an older driver that still uses the old Xinerama approach, you *might* find it works acceptably.
In my own testing, I've found cases where I could get displays across multiple cards (separate screens per-card) when running xrandr, but I ran into so many different bugs (mouse not working properly, X crashing, display corruption, etc.) that it was essentially unusable. Even if it could be made to work, this configuration is quite non-standard and not well tested. Resolving those issues will likely wait until the aforementioned architecture is fully in place. |
Binary package hint: xorg
[Problem]
X does not support (or does not support very well) displaying a desktop across more than one video card. When it is possible, a variety of bugs are experienced.
[Discussion]
Prior to the introduction of Xrandr it was (sometimes) possible to configure xorg.conf to display on multiple video cards. One could then use Xinerama, etc. to stitch screens into a contiguous desktop. Of course, any alterations to this setup usually required hand-tuning xorg.conf.
The introduction of Xrandr made a number of things much easier, however it is not good at handling the case of multiple video cards. It can handle dual-head displays, where both monitors are connected to separate outputs on the same video card, but does not work as well with outputs on two different cards.
The fundamental problem (as I understand it) is essentially that X can talk to only one physical "pool" of memory, and each card has its own physical pool. Recent developments including GEM and several kernel changes promise to remedy this by enabling these pools to be aggregated and managed as a single virtual pool. Once the X server and drivers are updated to utilize this new architecture, they should be able to support multi-card functionality with Xrandr as well as (and better than) the old Xinerama configuration, including reconfiguring the display without needing to edit xorg.conf or restart X.
[Exceptions]
As mentioned above, the problem is most notable with drivers that have switched from Xinerama to Xrandr. If you're using an older driver that still uses the old Xinerama approach, you *might* find it works acceptably.
In my own testing, I've found cases where I could get displays across multiple cards (separate screens per-card) when running xrandr, but I ran into so many different bugs (mouse not working properly, X crashing, display corruption, etc.) that it was essentially unusable. Even if it could be made to work, this configuration is quite non-standard and not well tested. Resolving those issues will likely wait until the aforementioned architecture is fully in place.
The closed source -nvidia driver still uses Xinerama (it never got around to implementing Xrandr), so you can achieve multiple head displays that way. The nvidia configuration tool will be able to construct the xorg.conf settings for you to achieve Xinerama multi-head.
|
|
| 2011-01-25 20:17:59 |
Bug Watch Updater |
xorg-server: status |
In Progress |
Invalid |
|
| 2011-01-25 20:17:59 |
Bug Watch Updater |
xorg-server: importance |
Medium |
Unknown |
|
| 2011-02-04 01:36:12 |
Bug Watch Updater |
xorg-server: importance |
Unknown |
Medium |
|
| 2011-03-13 21:32:25 |
Jun Abbott |
bug |
|
|
added subscriber Jun Abbott |
| 2011-05-11 14:52:55 |
Bryce Harrington |
xorg-server (Ubuntu): assignee |
|
Chris Halse Rogers (raof) |
|
| 2011-12-21 22:47:28 |
Bryce Harrington |
xorg-server (Ubuntu): status |
In Progress |
Triaged |
|
| 2011-12-21 22:47:28 |
Bryce Harrington |
xorg-server (Ubuntu): assignee |
Chris Halse Rogers (raof) |
|
|
| 2012-02-22 18:13:39 |
David Duffey |
bug |
|
|
added subscriber David Duffey |
| 2012-05-09 12:35:49 |
Davide Zilli |
bug |
|
|
added subscriber Davide Zilli |
| 2012-05-10 22:54:54 |
rmcd |
bug |
|
|
added subscriber rmcd |
| 2014-08-05 20:41:23 |
Hanusz leszek |
bug |
|
|
added subscriber Hanusz leszek |
| 2020-05-15 15:30:35 |
David Duffey |
removed subscriber David Duffey |
|
|
|
