X.Org

One of the first things I did when I joined the Cloud team at SUSE was to start porting DevStack to openSUSE. DevStack is a set of shell scripts to build complete OpenStack development environments. It is useful to create a small OpenStack ... [More] environment that will be used for hacking, testing, etc. and is therefore primarily used for upstream development. Getting this to work on openSUSE seemed like a logical first step before doing more OpenStack work. I got things working pretty quickly, but for various reasons, this all stayed in a personal branch of mine (except for a few preliminary patches). A few weeks ago, I got time for DevStack again. So I rebased my branch, cleaned up everything, and started submitting the patches. After reviews from Sean Dague and Dean Troyer (and some patch rewriting to address the issues that were raised), the openSUSE support landed in master. A few other people tested it, and nobody has been hitting any major issue, so yesterday, I finally submitted the patch to make openSUSE 12.2 a supported distribution. Now you can play with DevStack on openSUSE! I wrote some documentation for DevStack on openSUSE if you want to get more details on how to use it. But I guess it wouldn't hurt to show how easy it is to setup your own OpenStack environment this way... I'm shamelessly stealing instructions from the single VM DevStack guide to show you the very short version. Just run the following in an openSUSE virtual machine (do not run this on your main system unless you're 100% sure it's what you want: DevStack is a little bit too invasive right now; see Daniel's analysis on this topic): zypper in git-core git clone https://github.com/openstack-dev/devstack.git cd devstack echo ADMIN_PASSWORD=password > localrc echo MYSQL_PASSWORD=password >> localrc echo RABBIT_PASSWORD=password >> localrc echo SERVICE_PASSWORD=password >> localrc echo SERVICE_TOKEN=tokentoken >> localrc echo FLAT_INTERFACE=br100 >> localrc ./stack.sh (You'll actually need to call FORCE=yes ./stack.sh until the patch mentioned above gets in.) And there you go, you have OpenStack running! That was quite easy, right? :-) You can connect to the web dashboard (horizon) or use the command line tools (hint: source openrc will setup the proper environment variables for you). Here's a few commands you can use to get started: source openrc glance image-list # find out which image is available nova boot --image cirros-0.3.0-x86_64-uec --flavor m1.tiny cirros-test # start an instance of one specific image nova list # see what instances are in the cloud So go ahead, read the documentation, play with all this, and enjoy DevStack on openSUSE! [Less]

Another OS release came out today, 2010.11, and as usual, it has a number of X11 changes. The biggest change in X is probably... Hmm, I can see by the look on your face, you're not buying the casual use of “as usual” there. Okay, you caught me ... [More] , this OS release isn't quite following our previous pattern, so I guess we better get that out of the way first. Please remember I am not an Oracle spokesman, and can't speak on behalf of Oracle, so don't even think of quoting this as “Oracle says...” In many ways, this release is simply the continuation of the OpenSolaris distro releases of the last few years. It's built the same way, using the IPS packaging system and repositories, and Caiman installers, as the OpenSolaris 2009.06 and prior releases were. Where OpenSolaris 2009.06 (the last full release) was the biweeekly build numbered 111b, and the release we'd planned to put out as OpenSolaris 2010.03 earlier this year (and which made it to the package repository, but was not put up as downloadable ISO's) would have been biweekly build 134b, this release is 151a. You should be able to upgrade to it from OpenSolaris 2009.06 or OpenSolaris /dev builds via the package repository following the instructions in the 2010.11 release notes. So what's different about this OS release? Well, it's not named OpenSolaris anymore for starters - it's Oracle Solaris 11 Express. We'd always said that OpenSolaris releases were leading up to Solaris 11 eventually, and this name emphasizes we're getting closer to that (though still not there yet). It also recognizes that this release is built by Oracle, not Sun nor the OpenSolaris community. While it's built on the work done by the OpenSolaris community, and many portions of it are still developed as open projects on opensolaris.org, the kernel and core utilities are once again being developed behind closed doors, and the final assembly and testing are similarly done in house. The license terms for the free downloads have changed as well (though it's still offered under support contract for commercial production use as well), and the OS images include some of the encumbered packages we'd had to keep out of OpenSolaris in order to allow OpenSolaris to be freely redistributable. (Not all of them, since some were simply EOL'ed as they were for hardware well past the end of its supported lifetime, like many of the old SPARC frame buffers.) So with that out of the way, back to the topic at hand - what's new in the X Window System in this release? Well that depends on how far back you're coming from. You can browse the complete changelogs for X going back to the point we branched the Nevada branches from the Solaris 10 release, so I'll try to stick to the highlights. Changes since the last OpenSolaris X11 source release None, since the X sources on opensolaris.org are still updated automatically from our internal master gate on each commit. (In fact, since the source gates currently reflect a point between biweekly builds 153 & 154, they have changes newer than this release, such as the integrations of libxcb and FreeGLUT.) Changes since the last OpenSolaris developer build release (b134) There were 17 biweekly builds between the last one published to pkg.opensolaris.org/dev in March and this release. The biggest change in the X packages in this period was their packaging. Previously we built our packages using the old SVR4 package format that was used since Solaris 2.0, and in many cases following the breakdown used in the old Solaris 2 releases (SUNWxwinc for most headers, SUNWxwplt for most libraries, SUNWxwman for most man pages), and then the release team converted those to the IPS format used in the OpenSolaris releases. Like several of the other consolidations, X has now converted to building IPS packages directly, and in the process refactored the X packages to better follow the way the upstream X.Org sources were split into modules at X11R7, which also happens to be more similar to the way most Linux distros break them up. This should allow easier creation of minimized environments with the subset of X packages you need. As for headers and man pages, they are now included in the packages they are used with - for instance all the libX11 headers and API man pages are directly in the x11/library/libx11 package. System admins can still decide to include or exclude them in their installs though, since they are tagged with the devel and doc “facets”, which are the IPS mechanism for controlling optional package components. To read more about how to use these with X or the other changes in the refactoring, see the heads up messages I posted when this work integrated. Of course, there were also the usual updates to new upstream releases - Xorg 1.7.7, freetype 2.4.2, fontconfig 2.8.0, among many others. The X server packages now also include the mdb modules and scripts for getting client and grab information from the server that I blogged about back in April. Changes since the last OpenSolaris stable release (2009.06 / b111b) This period saw the completion of our multiyear project to completely replace the old Solaris X code base with the X11R7 open source code base from X.Org. Solaris 10 and earlier shipped with Sun's proprietary fork of X11R6, with bits of X11R5, X11R6.4, X11R6.6, & X11R6.8 mixed in. We're now set up to much more easily track upstream and are deviated from upstream in much fewer places than before (partially due to pushing a number of our previous fixes back upstream, in other cases, we determined the upstream code was better and went with it). We also had a very large user-visible change in build 130: all the files moved from /usr/X11 directly into /usr/bin & /usr/lib, following the work done in other parts of Solaris to move files from locations like /usr/ccs/bin and /usr/sfw to the common /usr directories. We still have symlinks in /usr/openwin and /usr/X11 for backwards compatibility, so we shouldn't break your .xinitrc calls to /usr/openwin/bin/xrdb or /usr/X11/bin/xmodmap. Since 2009.06, we moved from Xorg 1.5 to 1.7.4. Of course, with this upgrade, we got the HAL support for input device configuration working just as X.Org started moving off HAL upstream, something we still need to deal with for Solaris - for this release, input devices are still configured in HAL .fdi files. The xorgcfg and xorgconfig programs did go away as part of this move though - fortunately more and more systems are working without any xorg.conf at all, and when one is needed, only the sections being changed have to be included, lessening the utility of programs to generate full configuration files. The new Xorg also includes support for virtual consoles on systems with the necessary kernel driver support (all x86 systems and SPARCs with frame buffers supporting “coherent console”). We also added the synaptics touchpad driver, synergy software for sharing input devices with multiple systems, the simple xcompmgr composite manager, the xinput client for input device configuration, and finally provided IPS packaged versions of the classic xdm display manager and xfs legacy font server. The Xprint server and several related commands did go away, but the libXp library was kept for binary compatibility. Our VNC implementation was converted from RealVNC 4.1.3 to TigerVNC 1.0.1, which is being kept up-to-date with new Xorg releases, unlike RealVNC, which hasn't really been updating it's open source release in the last few years. xscreensaver was finally updated from 5.01 to 5.11, and was actually moved out of the X gate in OpenSolaris to building as a RPM-style pkgbuild spec file with the other higher-level desktop software - hopefully in the process we fixed some long-standing bugs in our forked code. Graphics updates included Nvidia's driver support for various new devices and OpenGL 4.0, and Intel's DRI updates, including GEM support in their DRM module. Mesa was added on SPARC to provide a matching OpenGL implementation, but with only the software renderer, no hardware acceleration. What else has changed? Besides the official Solaris 11 Express release information, you can find more details on changes in this release on a bunch of other blogs, such as: Darren Moffat on ZFS Crypto Deirdré Straughan's videos of the Solaris Summit at LISA10 last week and other recent Solaris 11 talks Overviews from the Observatory and OTN Garage (formerly BigAdmin) blogs But here's some changes in other parts of the OS you may not see listed on those: Solaris tar has builtin compression support (no option needed to extract .Z, .gz or .bz2 files, -j & -z options accepted for created), can unpack files created with GNU tar's long file name extensions, and is a bit friendlier in handling unpacking archives with absolute file names. Enabling Solaris Auditing records no longer requires reboot From the linker aliens: Ali Bahrami on the new linker mapfile syntax and Rod Evans on using hardware capabilities to choose symbols for specific ISAs. libc now includes strcasestr(), getline(), get_nprocs(), strndup(), ffsl(), ffsll(), and stpcpy(). libsocket now includes getifaddrs() kernel keyboard configuration moved to SMF The little used SYSV3 environment variable no longer enables ancient compatibility modes. Of course, that's just a small sample, the full changelogs are a few thousand items long (and unfortunately, some of the consolidations haven't published theirs outside the firewall). [Less]

The introduction of KMS and GEM into the i915 driver broke the i830/i845 chipsets, and a lots of hearts. But fear not! A decade after its introduction, we finally have a driver that is not only stable, but capable of accelerating firefox. The ... [More] problem? The problem was, simply, we could not find a way to enable dynamic video memory on the ancient i830/i845 chipsets without it eventually eating garbage. Since dynamic memory management was the raison d’etre of GEM and critical for acceleration, it is a requirement of the current driver stack. The first cunning solution was simply never to reuse batch buffers, and keep a small amount of memory reserved for our usage. This stopped the command streamer from seeing the garbage, and my system has remained stable for many hours of thrashing. Daniel Vetter extended my solution to implement a kernel workaround whereby every batch would be copied into a reserved area before execution. In the end, we compromised so that I could avoid that extra copy and assume responsibility in the driver for ensuring the batch was coherent, but the kernel would intervene for any non-cooperative driver. With these workarounds in place, we are finally able to run through the test suites. Which brought us to the next problem: The sad fact is that UXA is inadequate for the challenge of accelerating the Render protocol. If we compare with an architecture that was designed to accelerate cairo, SNA: We find a much happier result. In all cases the performance is at least as good as using a software rasteriser in the X server, and often much better than if we avoided the Render protocol entirely and did the rasterisation in the client. With a little more tuning, we may be able to achieve parity even in the worst case – if we can win on an old GPU with an ancient CPU (single core, virtually no cache and even less memory bandwidth) we should be able to excel on more recent GPUs and CPUs, and be more efficient in the process. Yet, the Render protocol is not the be-all-and-end-all of acceleration. We need to keep an eye on the basics as well, the copies, the fills and the uploads, to know if we are achieving our goals. The basic premise is that using the driver (and thus the GPU) is faster than just using the CPU for everything. (In reality, the choice is more complicated because we have to consider the efficacy of GPU offload for enabling the CPU to get on with other tasks and overall power efficiency.) 1: Baseline performance of Xvfb 2: SNA with acceleration disabled (shadow) 3: UXA 4: SNA      1        2       3       4    Operation --------  ------  ------  ------   --------- 277000.0    2.04    1.06    4.58   Char in 80-char aa line (Charter 10)  265000.0    2.15    1.11    4.83   Char in 80-char rgb line (Charter 10)  312000.0    0.66    0.15    1.38   Copy 10x10 from window to window    6740.0    0.90    1.56    1.75   Copy 100x100 from window to window     382.0    0.92    1.30    1.36   Copy 500x500 from window to window  268000.0    0.74    0.17    1.50   Copy 10x10 from window to pixmap    7260.0    0.87    1.43    1.85   Copy 100x100 from window to pixmap     376.0    0.94    1.28    1.37   Copy 500x500 from window to pixmap  154000.0    0.74    0.69    0.86   PutImage 10x10 square    1880.0    1.04    1.05    1.04   PutImage 100x100 square      87.1    1.03    1.02    1.01   PutImage 500x500 square  308000.0    0.58    0.46    0.66   ShmPutImage 10x10 square    6500.0    1.02    1.16    1.24   ShmPutImage 100x100 square     380.0    1.00    1.24    1.28   ShmPutImage 500x500 square  So it appears that using the GPU for basic operations such as moving the windows about is only at most a marginal win over using a shadow buffer (and often times UXA fails at even that). Overall then it seems that enabling UXA should bring nothing but misery. [Less]

We have confirmed the venue and the dates for the Developer Experience hackfest. The betagroup coworking space from Belgium has kindly offered us a room and connectivity for up to 30 people. This has the great advantage that we can attend to FOSDEM ... [More] on the weekend after. To attendees If you are going to attend, please add your name to the wiki page as a confirmed attendee. I'm trying to come up with a budget for the people in need for sponsorship, if that is your case, please send me an estimateof your flight costs ASAP!I am trying to sort out the accomodation story in the upcoming days, expect news soon.   [Less]

The main feature making up XI 2.3 is Pointer Barrier events. This feature was initiated by Chris Halse-Rogers and then taken up by Jasper St. Pierre and me, until it became part of (the proposed) XI 2.3. DISCLAIMER: This feature is proposed for ... [More] server 1.14 and we're currently seeking feedback. This post is to increase public exposure. Any changes to the protocol will be updated here. The usual conditions apply: a client must announce XI2.3 support with the XIQueryVersion() request to utilise any of the below. Pointer barriers Pointer Barriers are an XFixes v5.0 additions to restrict pointer movement. They were first available in server 1.11 (released Aug 2011). A pointer barrier is created by a client along a specific horizontal or vertical line of pixels. Relative input devices such as mice or touchpads will be constrained by this barrier, preventing the cursor from moving across the barrier. For example, GNOME3 creates a vertical barrier on the top-left screen edge. In a multi-monitor screen, flicking the pointer up to the Activities menu will constrain the pointer there even if there is a screen to the left of the menu. This makes the menu much easier to hit. The client can choose for the barrier to be transparent in specific directions. GNOME3's pointer barrier is permissive in the direction of positive X (i.e. left-to-right). Thus, moving from the left screen to the right is unrestricted, even though the pointer is constrained when moving in the other direction. A simple client that creates a vertical pointer barrier looks like this: Display *dpy = XOpenDisplay(NULL); int fixes_opcode, fixes_event_base, fixes_error_base; PointerBarrier barrier; if (!XQueryExtension(dpy, "XFIXES", &fixes_opcode, &fixes_event_base, &fixes_error_base)) return EXIT_FAILURE; /* vertical barrier from 20/20 to 20/100 */ barrier = XFixesCreatePointerBarrier(dpy, DefaultRootWindow(dpy), 20, 20, 20, 100, 0, /* block in all directions */ 0, NULL); /* no per-device barriers */ mainloop(); The above code will set up a barrier for all devices, blocking in all directions. Pointer barrier events As of XI 2.3, pointer barrier events are sent to clients when pointer movement is constrained by a barrier, provided that client created pointer barriers, the clients have the matching event mask set. Two new event types were added, XI_BarrierHit and XI_BarrierLeave. Both events are only sent to clients owning a barrier and are only sent to the window used to create the barrier (the root window in the example above). unsigned char m[XIMaskLen(XI_BarrierLeave)] = {0}; XIEventMask mask; mask.deviceid = XIAllMasterDevices; mask.mask_len = XIMaskLen(XI_BarrierLeave); mask.mask = m; XISetMask(mask.mask, XI_BarrierHit); XISetMask(mask.mask, XI_BarrierLeave); XISelectEvents(dpy, DefaultRootWindow(dpy), &mask, 1); XSync(dpy, False); while (1) { XEvent ev; XNextEvent(dpy, &ev); if (ev.type != GenericEvent || ev.xcookie.extension != xi2_opcode) continue; XGetEventData(dpy, &ev.xcookie); XIBarrierEvent *b = ev.xcookie.data; if (b->evtype == XI_BarrierHit) printf("Pointer hit the barrier\n"); else if (b->evtype == XI_BarrierLeave) printf("Pointer left the barrier\n"); XFreeEventData(dpy, &ev.xcookie); } An XI_BarrierHit event is first sent when the pointer movement is first constrained by a barrier. It includes some information such as the device, the barrier and the window. It also includes coordinate data. XI_BarrierHit events are sent for each movement of the pointer against this barrier, or along it, until the pointer finally moves away from the barrier again. "Moving away" means a move to different position that is not blocked by the barrier. if the barrier is vertical, the pointer moves to a different X axis value, or if the barrier is horizontal, the pointer moves to a different Y axis value, or the pointer moves past the barrier's end point Once the pointer does move away, a XI_BarrierLeave event is sent. A pointer that moves against a barrier, pushes against it for 3 more events and then pulls back will thus generate 4 XI_BarrierHit events and one XI_BarrierLeave event. Who gets events? Always the client that created the barrier, and only if the window has the event mask set. If the client has a grab on the device with the grab_window being the barrier window, the barrier events follow the usual grab event mask behaviour: if the grab event mask has XI_BarrierHit set, the event is delivered if the grab event mask does not have XI_BarrierHit set but the window mask does and owner_events is True, the event is delivered if owner_events is False and the grab mask does not have XI_BarrierHit set, no event is sent The above applies to XI_BarrierLeave events as well. If the client's grab has a grab_window different to the barrier window, or the device is grabbed by another client, event delivery is as usual. In all cases, if the device is grabbed, the XIBarrierDeviceIsGrabbed flag is set. Clients should use this flag to determine what to do. For example, the barrier that is used to trigger the GNOME overlay should probably not trigger if another client has a grab as it may interfere with drag-and-drop. Coordinates and time in pointer barrier events Barrier events contain two sets of x/y coordinates. First, the root coordinates which represent the position of the pointer after being confined by barrier (and screen extents, where applicable). This coordinate is the same you would get from a subsequent XIQueryPointer request. The second set are the delta coordinates (dx/dy), in screen coordinates, from the last pointer position, had the barrier not constrained it. So you can calculate how much the pointer would have moved and thus derive speed. The dtime field in the event helps you to calculate speed, it provides the time in milliseconds since the last pointer event. The deltas are calculated after taking pointer acceleration into account. XIBarrierEvent *b = ev.xcookie.data; double dx, dy; double speed; unsigned int millis; dx = b->dx; dy = b->dy; millis = b->dtime; speed = sqrt(dx * dx dy * dy) / millis * 1000; printf("Barrier was hit at %.2f/%.2f at %.2f pixels/sec\n", b->root_x, b->root_y, speed); Releasing a pointer from barrier constraints By default, a pointer barrier blocks all movement of relative input devices across a barrier. However, a client can opt to temporarily release the pointer from the barrier constraints with the XIBarrierReleasePointer request. To do so, the client needs the event ID of the barrier event. Since a pointer may bump against the same barrier multiple times before the client reacts (X is asynchronous, after all), the event ID serves to identify a set of movements against or along the pointer barrier. An event ID is assigned to the first XI_BarrierHit event, and then it remains the same until the XI_BarrierLeave event. This event is the last event with the current event ID, any future barrier events will have a new event ID. This approach may be familiar to you from dealing with touch events, that use a similar approach (touch IDs start at TouchBegin and are tracked through to the TouchEnd). To release a pointer and let it pass through the barrier, call XIBarrierReleasePointer(). XIBarrierEvent *b = ev.xcookie.data; ... if (speed > 200) { printf("Movement exceeds speed limit, allowing pointer to go through\n") XIBarrierReleasePointer(dpy, b->deviceid, b->barrier, b->eventid); XFlush(dpy); } If, when the request arrives at the server, the pointer is still trapped by the barrier, the barrier is now transparent and the pointer can move through it with the next movement. If the pointer moves away from the barrier after releasing it and later moves against this barrier again, it will be constrained once more (albeit with a different eventid). Likewise, if the pointer has already moved away and against the barrier again before the client reacted, the release request has no effect. If the release does succeed and the pointer moves through the barrier, the client gets a XI_BarrierLeave event with the XIBarrierPointerReleased flag. The pointer barrier hit-box As mentioned above, a XI_BarrierLeave event is sent when the pointer moves away from the barrier. This would usually require a 1 pixel movement (let's ignore subpixel-movement, our hand's aren't that precise). However, during testing we found that 1 px pointer-movement can still happen even when a user tries hart to move along the barrier, or even when pushing against the barrier. Thus, we implemented a hit-box of 2 pixels. Thus, a 1 px movement along the barrier still counts as hitting the barrier, and the pointer is not treated as having left the barrier until it leaves the hit-box. Testing the current state The current code is available in the barriers branch of the following repositories: git://people.freedesktop.org/~whot/inputproto.git git://people.freedesktop.org/~whot/libXi.git git://people.freedesktop.org/~whot/xserver.git An example program to test the feature is available here [Less]

This is the script of a short intro I've given at the Linaro@UDS memory management summit in Budapest in spring 2011. Yep, it's a bit old ...The core idea of GEM is to identify graphic buffer objects with 32bit ids. The reason being "X runs out of ... [More] open fds" (KDE easily reaches a few thousand).The core design principle behind GEM is that the kernel is in full control of the allocation of these buffer objects and is free to move the around in any way it sees fit. This is to make concurrent rendering by multiple processes possible while userspace can still assume that it is in sole possession of the gpu - GEM means "graphics execution manager".Below some more details on what GEM is and does, what it does _not_ do and how it relates to other graphic subsystems.GEM does ...lifecycle management. Userspace references are associated with the drm fd and get reaped on close (in case userspace forgets about them).per-device global names to exchange buffers between processes (eg dri2). These names are again 32bit ids. These global ids do not count as userspace references and don't prevent a buffer from being reaped.it implements very few generic ioctls: flink for creating a global name for a buffer objectopen for getting a per-fd handle to a buffer object with a global name close for dropping a per-fd handle. a little bit of kernel-internal helpers to facilitate mmap (by blending multiple buffer objects into the single drm device address space) and a few other things.That's it, i.e. GEM is very much meant to be as simple as possible.Driver-specific GEM ioctlsThe generic GEM stuff is obviously not very useful. So drivers implementquite a bit driver-specific ioctls, like:buffer creation. In recent kernels there is some support to create dumb scanout objects for KMS. But they're only really useful for boot-splashs and unaccelerated dumb KMS drivers. Creating buffers usable for rendering is only possible with driver specific ioctls.command submission. An important part is mapping abstract buffer ids to actual gpu address (and rewriting batchbuffers with these). In the future, with support for virtual gpu address spaces this might change.tiling management. The kernel needs to know this to correctly tile/detile buffers when moving them around (e.g. evicting from vram).command completion signalling and gpu/cpu synchronization.There are currently two approaches for implementing a GEM driver:roll-your-own, used by drm/i915 (and sometimes getting flaked for NIH).ttm-base: radeon & nouveau.GEM does not ...This still leaves out a few things that I've seen mentioned asideas/requirements here and elsewhere:- cross-device buffer sharing and namespaces (see below) and- buffer format handling and mediation between different users (excepttiling as mentioned above). The reason here is that gpus are a messand one of the worst parts is format handling. Better keep that outof the kernel ...KMS (kernel mode setting)KMS is essentially just a port of the xrandr api to the kernel as an ioctlinterface:crtcs feed (possible multiple) outputs and get their data from a framebuffer object. A major part of KMS is also the support for vsynced-pageflipping of framebuffers.Internally there's some support infrastructure to simplify drivers (all the drm_*_helper.c code).framebuffers are created from a opaque driver-specific 32bit id and a format description. For GEM drivers these ids name GEM objects, but that need not be: The recently merged qemu kms driver does not implement gem and has one unique buffer object with id 0.as mentioned above there newly is a generic ioctl to create an object suitable as a dumb scanout (plus some support to mmap it).currently KMS has no generic support for overlays (there are driver-specific ioctls in i915 and vmgfx, though). Jesse Barnes has posted an RFC to remedy this: http://www.mail-archive.com/[email protected]/msg10415.htmlGEM and PRIMEPRIME is a proof-of-concept implementation from Dave Airlie for sharingGEM objects between drivers/devices: Buffer sharing is done with a list ofstruct page pointers. While being shared, buffers can't be moved anymore.No further buffer description is passed along in the kernel, format/layoutmediation is to be handled in userspace.Blog-post describing the initial design for sharing buffers between anintegrated Intel igd and a discrete ATI gpu: http://airlied.livejournal.com/71734.htmlOther code using the same framework to render on an Intel igd and displaythe framebuffer on an usb-connected displayport: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-testing.git;a=shortlog;h=refs/heads/udl-v2GEM/KMS and fbdevThere's some minimal support to emulate an fbdev with a gem/kms driver.Resolution can't be changed and it's unaccelerated. There's been somemuttering once in a while to better integrate this with either a kmskernel console driver or by routing fbdev resolution changes to kms.But the main use case is to display a kernel oops, which works. Foreverything else there's X (or an EGL client that understands kms). [Less]