DisplayLink Linux Rotation
Posted on 02. Jan, 2010 by Bernie Thompson in udlfb
With a kernel framebuffer driver that supports defio (like the version of udlfb in testing at git.plugable.com), it’s possible to use the standard xf86-video-fbdev X driver, rather than a custom DisplayLink one.
One interesting gain is xf86-video-fbdev supports rotation with a custom option (note it disables DGA and xrandr when it rotated mode).
To enable, in the xorg.conf “Device” section, add a Rotate option, setting it to CW, CCW, or UD.
Section "Device" Identifier "dl" Driver "fbdev" Option "rotate" "CCW" Option "fbdev" "/dev/fb1" EndSection
One downside is rendering is significantly slower, as the extra work of rotation is done at the X level and the page-fault behavior of defio means even small updates refresh much of the screen. Here’s some numbers that can be compared to earlier posts (in non-rotate mode):
bernie@bernie-aspireone:~/git/misc-udlfb$ ./udlfb-perf.sh fb0 gtkperf -a Xlib: extension "RANDR" missing on display ":3.0". GtkPerf 0.40 - Starting testing: Fri Jan 1 09:47:20 2010 GtkEntry - time: 0.00 GtkComboBox - time: 3.73 GtkComboBoxEntry - time: 2.08 GtkSpinButton - time: 0.49 GtkProgressBar - time: 0.69 GtkToggleButton - time: 0.47 GtkCheckButton - time: 0.44 GtkRadioButton - time: 0.79 GtkTextView - Add text - time: 2.30 GtkTextView - Scroll - time: 1.24 GtkDrawingArea - Lines - time: 4.14 GtkDrawingArea - Circles - time: 4.56 GtkDrawingArea - Text - time: 4.11 GtkDrawingArea - Pixbufs - time: 0.90 --- Total time: 25.96 Quitting.. model name : Intel(R) Atom(TM) CPU N270 @ 1.60GHz model name : Intel(R) Atom(TM) CPU N270 @ 1.60GHz cpu MHz : 800.000 cpu MHz : 800.000 MemTotal: 2052144 kB Framebuffer Mode: 1920,1080 Rendered bytes: 1238913024 (total pixels * Bpp) Identical bytes: 1070725304 (skipped via shadow buffer check) sent bytes: 125732225 (compressed usb data, including overhead) K CPU cycles: 7478653 (transpired, may include context switches) % pixels found to be unchanged: 86.00 % Compression of changed pixels : 25.00 % Total CPU cycles spent per input pixel: 6 Total CPU cycles spent per output pixel: 59 USB Mbps: 35.52 (theoretical USB 2.0 peak 480)
Linux USB quirks on 2.6.32
Posted on 02. Jan, 2010 by Bernie Thompson in Programming
Doing development on udlfb on Linux 2.6.32, crossed paths with these two quirks.
The usb_skeleton.c sample driver appears to run afoul of this problem, resulting in a warn_on during bulk transfer completion, if done the way the sample recommends. Because completion routines can be called with irqs disabled, usb_buffer_free on dma-ready buffers can’t be called from them — which pushed the udlfb implementation to diverge from the skeleton model and pre-allocate a small set of urbs, and free only on driver disconnect.
Calls to usb_bulk_msg (simple synchronous bulk out) appeared to be silently failing for largish transfers (generally 16-32K). Nasty to track down, since no errors are returned. Caused removal all use of usb_bulk_msg from udlfb, except for transactions that are known to be small.
2020: The past decade of ambient computing
Posted on 01. Jan, 2010 by Bernie Thompson in Other
It’s Jan 1, 2020.
Ten years ago we were at the end of the “computer on every desk and in every home” era. The iPhone had begun moving computing off the desk and into the pocket. The most important application was the web browser for content, but operating systems still mattered for running applications.
Ten years later, we’re simply reaching the conclusions of some of those trends–the web browser is where nearly all applications live. An explosion of devices and user interface types running over invisible operating systems have emerged to make those applications accessible in different ways, more transparently integrated with our lives.
We’ve learned to live with the risks and benefits of keeping our data in the cloud, so any display anywhere–with touchscreen, keyboard/mouse, or voice for input–is our own personal computer.
The average family has a display in our kitchen. Continuous voice recognition is again a challenge for the next decade, but discrete voice recognition is ubiquitous. An idle mention of “weather” in a kitchen conversation triggers the display on the wall to show the forecast for coming days.
The phone in our pocket is also a primary computing device. We dock it at our desk to gain a large display, keyboard, mouse, speakers, etc. But all that is stateless. When we unplug and go, we have everything — again, most of which is in the cloud anyway.
A picture is worth a thousand words, and we have access to a lot of pictures.
Displays are everywhere, especially in our urban settings, perhaps overwhelmingly so. Whether signage for a particular store, a billboard, or a public terminal, they’re showing active, context-aware content.
At work, multiple displays are the norm for information workers. Any remaining conference rooms without multiple displays, multiple web cams, and smart integration between them are frustratingly crippled.
And all these displays and terminals are being driven by far fewer “computers”–often just one per house or room, or increasingly one off in a server farm. Perhaps the greatest innovation of the past decade has been a subtle one–we spend less time keeping our computers working, as we have fewer of them. We’ve pushed more of the complexity to fixed-function devices, online services, and computers that are remotely maintained.
Even as our computers have become even more essential to driving our great strides in genetics, materials, collaborative creativity, etc., computing has begun to disappear into the background of our consciousness. More ubiquitous, but explicitly on the mind less often.
And still, the more things change the more they stay the same. The singularity is always a few decades away, and so it is again for the decade ahead.
Recent Comments