I would appreciate it if you would reword your response. Because what I got out of it was "libhybris is bad because it needs device-specific changes", and I refuted with "libhybris is not device-specific", and then somehow you said that I made your point.
Bold text:I guess best would be to ask straight from Carsten Munk (Stskeeps @ freenode), the original developer of hybris. Or I might aswell ask myself:
22:36 < DeeGee> So how locked in is device using libhybris to certain driver/kernel version combination? Pandora's sucessor is probably going to be OMAP5 based, because all other chipset would require
libhybris + android drivers.
22:36 < DeeGee> http://boards.openpandora.org/topic/15560-soc-back-and-forth/page-45
22:37 < Stskeeps> basically: if you have a working android hw adaptation for it, which is typically a driver+kernel combo, then libhybris practically just uses hwcomposer and EGL/GLESv2
22:38 < Stskeeps> because that's what a given ODM delivers with it and is stable
22:38 < Stskeeps> this may not necessarily apply to custom hw, though
22:39 < Stskeeps> remember that libhybris just is a way to leverage an android hardware adaptation
22:40 < Stskeeps> libhybris doesn't particularly care about kernel version
22:41 < Stskeeps> and X11 based BSPs with working GLESv2 is getting more and more rare
22:42 < Stskeeps> if i was to make a pandora device; i'd simply make a device that focuses on the good gaming experience, forget about the kernel version..
22:43 < Stskeeps> because with sufficiently mobile like devices, you're simply stuck with a certain kernel and the manpower needed to really upgrade is obscene
22:43 < Stskeeps> which you could better use to make new product; or better experience on what you hav
22:43 < Stskeeps> e
Well, it's a bit different with Imagination, AFAIR.
Replace "needs" with "would need" and you've got what I said. We're in the context of what would be required if the kernel changes so as to be incompatible with the driver.
(emphasis for clarity)There's nothing device specific currently in libhybris, but if the kernel changes so as to be incompatible with the driver and we want to upgrade then something needs to do the translation: you start adding device specific code, a branch from the device non-specific version, and it'll be hard to get anyone to maintain that.
That's likely due to only having a passing knowledge of it. Most of my friends only know the Pandora as a gaming device, because that's the part that is most important to me, so that's the part that they hear about the most.
Considering we've got, what, 7? 8? running on the Pandora, all produced by individuals (or perhaps small groups? not sure on all of them), I would say it isn't obscenely difficult.
As far as I'm aware, unless something has changed. The kernel module is open source with a binary blob for the actual communication with the hardware: changes to the kernel and any calls made can therefore also be made in the open source module without needing to change the binary.
Well, if this is actually true, then we wouldn't even need libhybris to use the android driver... Because we could just modify the kernel module to work with our kernel, right?
I thought we were talking about the A80 and how it is to be used on the Cubieboard.
We were talking about how we could use the Android driver assuming that the provided Linux driver (assuming there is one) was old. At least as far as I was aware that was the point of conversation.
I'm still not seeing that. If the bionic code gets translated to glibc calls, there shouldn't be anything kernel specific that would break compatibility when you move to a new kernel.
Basically libhybris doesn't give you hardware acceleration, driver does. And in android world, driver is typically tied with specific kernel version. This means we're stuck to old kernels and no support from manufacturer in 2 to 3 years.
No, it's the opposite, ED has no way of getting an A80 dev board in a reasonable time frame to consider it for Pyra production.The A80 may happen sometime in the distant future as an upgrade.
Probably not, but a lot of people would be against being locked to an old kernel for some pretty good reasons. It'd ultimately be ED's call but it really sounds like this is unacceptable to him.
If Cubieboard really is coming out next month - and that's a huge if - it might be more realistic to buy it instead of the Optimus board. Has anyone tried asking them (Cubieboard) what their expectations are for Linux drivers when they ship?
