Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
A bit lopsided
Posted Mar 5, 2013 15:10 UTC (Tue) by tetley80 (guest, #88691)
That's a good point. To be honest, I'm not that familiar with SurfaceFlinger. To (partly) answer your question: two wrongs don't make a right. Perhaps Canonical/Ubuntu should adopt and extend SurfaceFlinger instead of rolling their own display server?
On a related note, I'm starting to think that the most effective method to make Linux more relevant in the desktop space (and at the same time get a relatively sane OS stack: kernel, graphics, sound, input, UI) is to make Android self-hosting.
Posted Mar 6, 2013 1:14 UTC (Wed) by robclark (subscriber, #74945)
Posted Mar 6, 2013 4:04 UTC (Wed) by swetland (subscriber, #63414)
Other discussion in this thread seems to imply Wayland only recently declared the protocol stable. Is this another "Android should abandon <thing they built that works today> in favor of <thing that's not done yet that's clearly going to be better because!>" discussion?
Posted Mar 6, 2013 4:15 UTC (Wed) by hummassa (subscriber, #307)
why oh why? those days (4.2.2), two out of five times I have to restart BT on my Nexus when I enter my car, just "because!"
Posted Mar 6, 2013 12:35 UTC (Wed) by nye (guest, #51576)
Posted Mar 8, 2013 19:12 UTC (Fri) by hummassa (subscriber, #307)
Posted Mar 6, 2013 4:39 UTC (Wed) by robclark (subscriber, #74945)
Anyways, certainly in the early days, SF wasn't in good shape for hotplug, multiple displays, vblank support, and these sorts of things that matter on desktop.
Anyways, re: protocol stability, I somehow doubt you could claim that SF is backwards compatible to SF from 2006. The protocol stability milestone should have mattered very little to something that is distributed and updated in the manner that android is.
And re: abandoning SF and going to wayland.. well, android has made equally big changes in it's plumbing from release to release. So it doesn't seem too big a stretch of the imagination.
Posted Mar 6, 2013 7:03 UTC (Wed) by swetland (subscriber, #63414)
First public exposure to SurfaceFlinger would be Fall 2007 (SDK preview release and emulator) and first code drop would be Fall 2008 (Android 1.0 and G1 launch), but it's certainly something that was there from the very early days of the platform -- possibly late 2005, but certainly early 2006.
The hwcomposer HAL actually aims for some level for forward/backward binary compatibility (to ease development and upgrades), and while it doesn't reach back to the early days of SF (which has definitely evolved over the years), I just this week have been writing some test code for the HWC HAL that happily runs on a variety of devices from different OEMs and with different versions of the platform.
I'd be pretty doubtful about us shifting away from SF (especially now that hwcomposer and sync support is looking pretty solid), but we certainly are willing to pull things up and rebuild if necessary -- though the other commenter with his bluetooth complaint may be actually arguing *against* that, I guess.
From the other direction, though, unlike the earlier (now abandoned, I gather) work to stack Wayland on top of Android underpinnings, the hwcomposer HAL provides a much more flexible and richer surface than the old fb HAL, which certainly should be useful to the Canonical folks with their Mir compositor, as well as to anyone wanting to revisit a Wayland-on-Android world, though in both cases I'd assume the goal would be to get access to a wide variety of hardware ready to run "out of the box" rather than to actually use much of Android.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds