It's the details that take longest (Part 3)

[notaz]

Does it mean that Android support could be buggy because of the driver? (not that I care much anyway, just asking).

The drivers for Linux and Android are different, I don't know if anyone of us tested Android yet (at least I haven't and don't have any plans to do it).

 

[TrashyMG]

The drivers for Linux and Android are different, I don't know if anyone of us tested Android yet (at least I haven't and don't have any plans to do it).

I could give the OMAP5432 Android test image a whirl on the devboard if I have time, but Work has been very busy recently so not sure when I can fit it in. 

 

[Silent-Hunter]

I don't want to have to use Wayland, as I was planning to port CDE to the Pyra.

I don't mind binary blobs, but if they mean X11 can't be used, then maybe you should try writing your own.

 

[trololololo]

Is a binary "blob" such a bad thing? I mean, even if not open source, as long as it does it's job fine I'm OK with every solution. And if a closed source driver is faster than an open source driver, use the closed one!

The problem is that the blobs in question are not standalone programs, but libraries linked against specific versions of system's key components. So if we have e.g. a kernel module blob linked against one kernel version, we're stuck with that kernel version. If we have a blob linked against Xorg, we're stuck with that version of Xorg.

It's pretty obvious that those versions will become outdated very soon.

 

[codifies]

*sigh* binary blobs are sure a PITA but you have to be pragmatical (if grugingly!) I have to say I've been spoilt by intels HD4000 its genually a breath of fresh air and the i915 driver really rocks

I just can't wait for the day when such GPU's are developed such their price and TDP make them practical to go in something like the Pyra... Lets just hope that Intels example and extra sales (I won't even look at another manufacturer for a laptop now!) make a good example for other chip designers (ahem ARM!)

I do hope the community can develop their own drivers wrapped round any blobs that might be needed as that will mean an easier life later (Xorg and/or wayland could be buffered from the blob by a wrapper driver)  This approch would also mean it would be possible to make special profiling drivers, one thing I've actually used on an i915!

 

[trololololo]

I don't want to have to use Wayland, as I was planning to port CDE to the Pyra.

I don't mind binary blobs, but if they mean X11 can't be used, then maybe you should try writing your own.

Wayland supports X11 emulation via the XWayland server. Right now it's pretty flaky (both in compatibility and performance), but it's bound to improve as Wayland matures. There's no technical reason for it to be slower than native X11 - only lack of manpower to make it so.

I expect it to be production-quality at the time Pyra hits the market.

 

[vinipsmaker]

I don't want to have to use Wayland, as I was planning to port CDE to the Pyra.

I don't mind binary blobs, but if they mean X11 can't be used, then maybe you should try writing your own.

Wayland supports X11 emulation via the XWayland server. Right now it's pretty flaky (both in compatibility and performance), but it's bound to improve as Wayland matures. There's no technical reason for it to be slower than native X11 - only lack of manpower to make it so.
I expect it to be production-quality at the time Pyra hits the market.

I think only applications are supposed to be supported by XWayland, not window managers. And aside from that, compatibility is quite good, actually.

 

[Silent-Hunter]

It just seems like a needless complication to me.

 

[fusion_power]

Is a binary "blob" such a bad thing? I mean, even if not open source, as long as it does it's job fine I'm OK with every solution. And if a closed source driver is faster than an open source driver, use the closed one!

The problem is that the blobs in question are not standalone programs, but libraries linked against specific versions of system's key components. So if we have e.g. a kernel module blob linked against one kernel version, we're stuck with that kernel version. If we have a blob linked against Xorg, we're stuck with that version of Xorg.

It's pretty obvious that those versions will become outdated very soon.

That would be indeed very bad. Not sure if the companies update their blobs in a regulary base to keep up with kernel updates but I guess it would be onto the safe side not to be dependent onto the official driver updates.

 

[sebt3]

Don't they consider anything for tablets with Wayland though ?

Yeah, I was under the impression that wayland was intended for mobile.

 

[trololololo]

I don't want to have to use Wayland, as I was planning to port CDE to the Pyra.


I don't mind binary blobs, but if they mean X11 can't be used, then maybe you should try writing your own.

Wayland supports X11 emulation via the XWayland server. Right now it's pretty flaky (both in compatibility and performance), but it's bound to improve as Wayland matures. There's no technical reason for it to be slower than native X11 - only lack of manpower to make it so.

I expect it to be production-quality at the time Pyra hits the market.

I think only applications are supposed to be supported by XWayland, not window managers. And aside from that, compatibility is quite good, actually.

There is no reason why an X11 window manager couldn't run under XWayland and manage other X11/XWayland clients. There is no way for it to manage native Wayland clients - but if you intend to create a full X11-only environment, that should not be a problem.

And yes - normal X11 applications already run pretty well under XWayland. The flakiness appears around more specialized corners of X11 like window management, EWMH, etc.

 

[Wrath Of Khan]

And so in other news...wrath of khan has significant store credit with ithic, towards a pyra. Ed and link have salvaged yet another of Craigs debacles, namely the icp2. Roll on pyra.

 

[trololololo]

Is a binary "blob" such a bad thing? I mean, even if not open source, as long as it does it's job fine I'm OK with every solution. And if a closed source driver is faster than an open source driver, use the closed one!

The problem is that the blobs in question are not standalone programs, but libraries linked against specific versions of system's key components. So if we have e.g. a kernel module blob linked against one kernel version, we're stuck with that kernel version. If we have a blob linked against Xorg, we're stuck with that version of Xorg.

It's pretty obvious that those versions will become outdated very soon.

That would be indeed very bad. Not sure if the companies update their blobs in a regulary base to keep up with kernel updates but I guess it would be onto the safe side not to be dependent onto the official driver updates.

I wouldn't count on updates. Typically, these are done very intermittently, and only for as long as the hardware in question is current. As soon as TheNextBigThing™ is released, the previous one is left to rot.

Remember this is not PC hardware that is supposed to support a range of OSes over the years. These are embedded parts that are expected to be used in a self-contained system designed in its entirety (hardware+software) up-front, and then used without any modifications (except maybe minor bugfixes) for its entire service life.

 

[comradekingu]

What rotary potentiometer is selected for audio?

 

[levi]

Regarding wifi chips, I'm no sort of expert, but I found the 802.11n usb nubbin sent by ED when I bought my Pandora to be much more stable than the internal chip. But I've no idea if it contains a chip we can wire up to the CPU via a mechanism other than tying up a USB line, and I guess the chip might be out of production anyway.


But that brings me to a small concern - audio quality with USB host enabled. When I turn it on and listen using my 'good' heaphones, I hear kicks and pops which, while they do mostly get drowned out when music is played, can make it a little difficult to check audio tracks for glitches. With the Pyra having even more USB ports, could this make the problem worse there?

 

[Neelix]

But that brings me to a small concern - audio quality with USB host enabled. When I turn it on and listen using my 'good' heaphones, I hear kicks and pops which, while they do mostly get drowned out when music is played, can make it a little difficult to check audio tracks for glitches. With the Pyra having even more USB ports, could this make the problem worse there?

I also noticed this with my Pandora,  it was especially noticeable when I connected my pandora both to my Midi keyboard and external speakers at the same time.   Now that I think on it I wonder if the same issue is what causes the pops and clicks when attempting to use the gadget audio driver.    Either way, I'm seconding Levi's request to look into and hopefully fix this issue.

- Neelix

 

[qwer]

The Marvell 88W8797 (datasheet) might be another option for Wifi. There seem to be versions with USB and SDIO interfaces and the driver is GPLed and already part of the linux kernel (while still requiring a firmware blob). Since it's used in the Surface Pro 1&2, it would be reasonable to assume that the driver is somewhat well-tested, like the Realtek / Broadcom chipsets. Also comradekingu already mentioned it, along with some other options.

 

[DaMummy]

No offense to ED, and I'm sure hes good at what he does at his dayjob, but am I the only one who would trust MWeston more with the audio equipment here? proven track record and all that

 

[EvilDragon]

I'm not sure MWeston has 20k EUR or more studio equipment lying around at home... no worries, I know how to do my job. I couldn't design an audio circuit, but I sure can measure the quality.


We've also planned and installed complete installations for half a million EUR, btw.

 

[Letalis Sonus]

Since it's used in the Surface Pro 1&2, it would be reasonable to assume that the driver is somewhat well-tested

Is it even possible to drive those with another OS? As MS requires to lock down all Windows ARM devices so hard that doing that is simply impossible, I'd expect that they would do the same with their own x86 tablets.