hybrid-graphics-linux team mailing list archive

[Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxx>]

Blueprint changed by Maarten Lankhorst:

Whiteboard changed:
  UDS-Q notes: http://pad.ubuntu.com/uds-q-desktop-q-hybrid-graphics
+ 
+ Continuation of last UDS' hybrid graphics session.
+ What is possible to accomplish during this cycle?
+ Currently, kernel drm subsystem feeds is complete.  Most is queued for 3.5 kernel.
+ If the binary drivers are allowed to hook into the DMA buffer modules is an open question.
+ The outcome was that the drivers were going to remain GPL only, although they'd like other drivers to plug into that.  That will either happen or it won't.
+ Need to contact the nvidia folks to see what the status is.
+ Won't be useful until the xserver supports it.  which version?  unlikely this cycle, because the changes are huge.
+ Dave has sent a number of patches to the xorg-devel list for review.  That would make it easier to actually test this.  The patches decouple the X DDX from the protocol screen, so you can have multiple DDX feeding the same screen.
+ How do you work out which GLX to load via mesa?  Don't know... something we can reasonably do here.
+ Rather than loading one GLX or the other, we'd need to load both.
+ Switching GPUs on the fly is slightly different, but the patches should allow running one X server ...
+ ARB robustness implementation in mesa would take about a week's work.  (And needs piglit testing)
+  Things using the desktop compositor could potentially permit some level of switching? (This should be *desperately* out of scope for Q)
+ Another option to put effort in around some of the current temporary workarounds (Bumblebee, et al).
+ If the proper upstream design is coming soon, then might be better focusing on that and continue encouraging community support for
+ the temporary solutions.
+ Another option is to put some time upstream somehow.  E.g. Provide review to dairlie's upstream patches.
+ If this helps ensure the work matures quickly, this might be the lowest hanging fruit for us.
+ How about powering off the the GPU not in use.  RAOF developed a prototype to do this last cycle.
+ It uses VGA switcharoo to turn off the one it believes is not active.
+ Put this into package that users can opt into using?
+ Testing in a desktop case might be feasible, using two discrete cards.  Might also be possible to
+ do an an internal + discrete combo *if* the BIOS does not shut off the Intel card when a discrete
+ card is present (or if it can be toggled on/off)
+ UI issues.  If it looks like we'll get it for next cycle then it might be worth discussing UI design
+ at that point.  This cycle *maybe* worth collecting some rough mockups? And try to list the various usecases to aid the ui design process.
+ open questions:
+ 
+     - ddx patches, apparently dave has done some work on uxa support,
+ intel is concentrating on sna: http://cgit.freedesktop.org/~airlied/xf86
+ -video-intel/log/?h=drvmodelv3
+ 
+     - acpi management with prime, currently no proposals in how to
+ handle it
+ 
+     - 'bbswitch' from the bumblebee project might be useful
+ 
+     - This wiki page contains a table with working ACPI calls to turn
+ off/on cards: http://hybrid-graphics-
+ linux.tuxfamily.org/index.php?title=ACPI_calls (note: these calls may
+ not be correct at all, see the huge warning on the top!)
+ 
+     - Also, this bug report has a collection of DSDT tables:
+ https://bugs.launchpad.net/lpbugreporter/+bug/752542
+ 
+     - which prime modes are possible in this and the next cycle?:
+ http://cgit.freedesktop.org/~airlied/xserver/tree/drv/TODO?h=drvmodelv2

-- 
Hybrid graphics support strategy planning for Q
https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-hybrid-graphics