Hell Labs

While I was updating the fastinit reimplementation with Metalshark’s patches, rallying enthusiast and Eeepc owner Ednilson Miura pointed me to a discussion in EeeUser about increasing screen resolution of the Eeepc display, basically by scaling down a higher resolution desktop to the native 800×480 Eeepc display. We’ve seen different approaches to solve the low resolution problem, from the traditional viewport to a larger virtual desktop to real screen rescaling (Intel has a driver-based rescaler for its Classmate PC, and there are similar resampling technologies used in other manufacturers with Eeepc-similar offerings usually with quality ranging from barely readable to unreadable). The aforementioned discussion presents a somewhat novel approach: a VNC connection to the local host. I think we could get a similar effect with a more elegant and less resource-intensive solution: X compositing. It would also be one of the first non-frivolous utilities for desktop compositing, previously used almost only for eye-candy. RandR and driver-based rescaling approaches are also discussed below.

Compositing

Since the Eeepc has a reasonably decent video controller which is well-supported by Xorg’s DRI, using a composite manager to “zoom out” a larger desktop could be quite easy, offering a nice OpenGL-based anti-aliased rendering with different zoom levels. All the technologies needed are available, and the easiest way to implement this would be, I think, through a Compiz plugin. Once the proof of concept works it could be reimplemented as a slimmed-down, composite-aware window manager that could better suit Eeepc users needs (or even keep Compiz if it’s good enough for the task). A similar approach could be used in the Classmate PC as well, but other Eeepc-like laptops (such as the NanoBook) with non-Intel video chips probably won’t work quite well with this approach due to OpenGL texturing performance (but would Xv-based desktop rescaling work?).

Compositing is also overkill if we’re going to resize the entire desktop, unless we want different zoom levels for individual windows, which would also require more sophisticated input transformation to work.
 

RandR (update 2008-02-15)

Following Dirk’s advice below I asked Keith Packard about his thoughts on this subject. This is his reply:

RandR already supports a full shadow frame buffer for rotation and applies a transform using the Render extension to draw to the displayed frame buffer. All that is needed is to change that transformation from a rotation to a scale, and then expose that transform through the RandR protocol. There isn’t any driver-specific work needed at this point, the solution would work with any RandR 1.2 capable driver.

and

I’ve pushed the proposed protocol changes to the ‘transform-proposal’ branch of the randrproto repository; it’s all fairly straightforward from a protocol perspective. The ‘implementation’ I did was purely a proof-of-concept at the lowest level, ensuring that a non-rotation transform would work to scale the output. The protocol changes and actual transform computations were not implemented at all; I used RandR output properties instead. Those will not work as they don’t expose the correct visible size of the screen to applications, making them all place menus in the wrong spots.

Dirk: Maybe some pointers to dos and donts would help?

I think the key is to leave the existing mode infrastructure in place and conditionally call back from the driver to the RandR extension to check for a transformation, applying that as necessary within the existing ‘rotation’ code.

Further information on RandR and Render extensions can be found at X.org and the RandR paper by Jim Gettys and Keith Packard. You may also want to have a look at some notes on RandR 1.3 from the 2007 X Developer Summit.
 

IEDG and driver-level scaling (update 2008-02-17)

The Intel Embedded Graphics Driver is discussed in the EeeUser forum. The advantage of a X-based approach over IEGD would be the possibility to work with non-Intel hardware (in Nanobook/Cloudbook and other ultramobiles) allowing a third-party distribution to support a wider range of hardware in a uniform way. Additionally, IEGD is closed-source and does not offer compositing capabilities.
 

Classmate driver-level scaling (update 2008-03-01):

The Classmate mini-laptop also uses a driver-based rescaler which is not the IEGD. The screenshot below shows a portion of a vertically compressed screen, which is quite unreadable:

Summary

This entry was posted on Thursday, February 14th, 2008 at 10:38 pm and is filed under eeepc, en, linux. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.