Raspberry Pi Is Running Well On Wayland/Weston

[pq__]

Well at the end I was just curious of how backends are implemented on wayland , statically or dynamically like drivers do. I was thinking on the stupid scenario (that may never happen) where you have a PC based on a SOC and the wayland backend was developed specifically for it. Now if that SOC got damaged and you have the OS installed on some external drive, you would just buy a new SOC, but that new SOC uses another wayland backend. Would wayland would automatically detect which backend is compatible for current used hardware like the drivers system does?

Wayland does not have backends. Wayland is a protocol.

libwayland (server, client) does not have backends either, it just turns the binary protocol into nice C functions in a generic way.

Compositors can have backends, and Weston does too. Each compositor can load backends in any form they want. The stupid scenario is possible with compositors, unfortunately. If the hardware drivers do not implement what we think as standard APIs (say Linux KMS, EGL, and GBM; or OpenWF, hell even the /dev/fb framebuffer API), it's really a choice between "these particular compositors are the only Wayland servers that run on this exotic piece of hardware" vs. "no Wayland server runs on this hardware". Btw. I think you could run Weston with the generic fbdev backend on RPi, but you would get bored waiting for the screen to update---I never even tried.

Clients, applications, and toolkits on wayland do not have backends (in the sense we are talking about here), but they rely on standard APIs like EGL and OpenMAX to take advantage of hardware acceleration. This means that someone (usually a platform vendor or such) provides libraries that implement these standard APIs, and then applications link to them at runtime. Whether Wayland-enabled implementations of these standard APIs exist on a particular platform is a whole another question, but the Wayland client side does not require platform specific changes in applications or even toolkits.

However, an excellent question is, do standard APIs exist for everything the hardware could accelerate. That is the key to avoid making applications platform-specific.

In summary, if hardware does not come with the kind of drivers we expect, well, too bad. We may be able to work around that like with RPi, or maybe not. Sometimes it is possible to write new drivers the way we want them, and sometimes it is unrealistic.

[Serge]

My point is that you don't need an rpi to do the things that can be interesting WITH an rpi. There are devices out there more specifically tailored for those things that would be MUCH more interesting FOR those things. Like ARDUINO, for example.

Fair enough. Arduino products are interesting in their own right and are probably superior to the RPi for most automation related stuff. I get the impression that there are some use cases where the RPi shines, but I haven't had time to explore this stuff in the way that I would like.

My principle interest at the moment is in a computing device that can act as a Synergy server. Synergy is a program that shares input events (keyboard and mouse) on a computer running Synergy in server mode to computers running Synergy in client mode. It's essentially a software KVM, minus the V part. I use my primary desktop computer as a Synergy server, but this is a power-hungry machine and I don't leave it on when I am not using it. I've been thinking of switching to a cheap, low-power SBC that I can leave on 24/7 for this purpose. The device's graphical performance is of no interest to me, as I don't plan on connecting this device to a display anyway. I only need it to be able to run the bare minimum necessary to run Synergy as a server. Performance requirements are minimal, and I'm more interested in price. What I had previously read gave me the impression that the RPi would be ideal for this purpose. As I said, I haven't had time to explore this stuff in detail, so perhaps I am wrong. But at least given my own personal, narrow interests, I consider the RPi to be a worthwhile product.

But as I said, I haven't explored the options in detail, so I freely admit that I may be wrong and that there may be cheaper devices that would accomplish this purpose.

[erendorn]

It doesn't matter [some probably interesting stuff], bye.

Please, do not use "crapium", "micro$oft", "iPoo" and the like, it makes you look like you are 12.

[pq__]

Does anyone know if it's possible to at the same time have the Raspberry Pi output to the HDMI and RCA video two different images, screens?

If not would the improvements in wayland and recent improvements in hardware accelerated compositing allow for such things on the Raspberri Pi?

That's a very good question I wondered about myself recently. I never really asked about it, had enough to do with just lighting up the HDMI output, and I don't even have a composite sink to test with. (I wrote the original rpi-renderer currently in weston upstream, hi!)

But I'm almost sure we are not the first ones to think of it, so there should be an answer in the intterwebs somewhere, whether the hardware/firmware is even capable of it...

[c117152]

Yours and my definition of "fast enough" differ significantly.
Also, I *have* an rpi. The damned thing can barely handle an HD video with its hardware decoder, because the AUDIO overwhelms the CPU.

I now use it as a SPA controller.

It's all software and licensing issues(http://wiki.xbmc.org/?title=Raspberr...i_can_playback). Audio especially since there are a whole bunch of audiophiles tinkering with their power supplies and software stacks and are getting some very good results: http://www.electronicsweekly.com/new...ry-pi-2013-07/

Disclaimer: I have one too. But I mostly use mine to benchmark C routines I'm too lazy to profile and want to keep highly portable through targeting 9pi. So, I don't really get to use the Audio/Video (or even web surfing) all that much except out of occasional boredom... I did use it as a make shift remote temperature monitor for a while. Intel's MB and CPU sensors lie and die...

I suppose if we're fantasizing about a dream machine, I'd like a MIPS64 with FOSS video drivers as a desktop...

[droidhacker]

I understood your suggestion but it appears that I misunderstood your intent. Can you clarify (and sans the rudeness this time please), then, if what you were in fact trying to say was boring to you was what you perceive to be as a focus on desktops? The way I read it, I got the impression that you were trying to say that the RPi as a whole is boring for you and that only an SBC with greater focus on desktop use would be interesting.

If I understand you correctly NOW, then: 1) I am sorry for having misunderstood you previously; and 2) I agree that focusing RPi development on improving its use as a desktop replacement is not very interesting.

My point is that you don't need an rpi to do the things that can be interesting WITH an rpi. There are devices out there more specifically tailored for those things that would be MUCH more interesting FOR those things. Like ARDUINO, for example.

[droidhacker]

Wow some retarded benchmarks that no one actually knows how they are calculated and what a score of X means and if the points scale linear.

Look at some Linpack stats.

http://www.roylongbottom.org.uk/linpack%20results.htm

It doesn't matter WHAT it is testing, only that it is testing the SAME STUFF on all the chips.

A linear scale doesn't matter. What is bigger matters.
Yes, we do know what everything means and how everything is calculated;

http://www.tux.org/~mayer/linux/bmark.html

HAHAHAHA
rpi at high OC is not far off of a crapium 3-1100....
Raspberry Pi ARMv6-compatible Proc rev 7 (v6l) oc High: 950MHz ARM, 250MHz core, 450MHz SDRAM, 6 overvolt ? Linux 3.2.27+ gcc-4.6.3-14+rpi1 libc-2.13 3.253 4.219 2.613
Pentium III 1.1GHz ? Suse Linux 8.0 gcc-2.95.3 20010315 ? 4.941 4.178 9.763


Ah, here it is... partial results for p3-700:
Intel Pentium III 700 MHz 133 MHz bus ? Red Hat Linux 7.1 gcc 2.96 20000731 ? 4.464 3.866 8.417



In any case, what we have here is an example of some dipship (that would be you) making stupid claims without providing ANY numbers to back them up.
I'm sure that lots of other dipshits will fall for that and believe you, but you got called out on it this time and lost. BADLY.

Also, it wouldn't hurt for you to actually read the stuff in links you provide to support your claims.... because that link does NOTHING to help support your claims. Quite the opposite, they support MY claims. To such an extent that it is TRULY HILARIOUS.


So thanks for playing, bye.

[droidhacker]

The RasPi's hardware is fast enough. The lack is in the software. First there's the closed GPU drivers that won't let you composite properly or playback video with gstreamer. And then, there's the unoptimised JavaScript interpreters.

If you have a unit, put on the newest Raspbian or even RiscOS and try out netsurf. I find it preforms exceptionally well as long as video and JavaScript aren't involved.
There's also a few free FPSs in Raspbian available that are running circles around anything that p3 could handle.

It's actually a very good demonstration of just how bad JavaScript really is...

Yours and my definition of "fast enough" differ significantly.
Also, I *have* an rpi. The damned thing can barely handle an HD video with its hardware decoder, because the AUDIO overwhelms the CPU.

I now use it as a SPA controller.

[Serge]

... I've suggested automation. What about that do you not understand?
Also, with all the bogus "developments" they're working on, THEY are clearly focusing on graphical desktops.

I understood your suggestion but it appears that I misunderstood your intent. Can you clarify (and sans the rudeness this time please), then, if what you were in fact trying to say was boring to you was what you perceive to be as a focus on desktops? The way I read it, I got the impression that you were trying to say that the RPi as a whole is boring for you and that only an SBC with greater focus on desktop use would be interesting.

If I understand you correctly NOW, then: 1) I am sorry for having misunderstood you previously; and 2) I agree that focusing RPi development on improving its use as a desktop replacement is not very interesting.

[TheOne]

The RasPi's hardware is fast enough. The lack is in the software. First there's the closed GPU drivers that won't let you composite properly or playback video with gstreamer. And then, there's the unoptimised JavaScript interpreters.

If you have a unit, put on the newest Raspbian or even RiscOS and try out netsurf. I find it preforms exceptionally well as long as video and JavaScript aren't involved.
There's also a few free FPSs in Raspbian available that are running circles around anything that p3 could handle.

It's actually a very good demonstration of just how bad JavaScript really is...

At least running less powerful hardware helps developers optimize their software so it can perform better on such environments, thanks to raspi theres now PyPy support for arm and some other cool stuff