Announcement

Collapse
No announcement yet.

Raspberry Pi Is Running Well On Wayland/Weston

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #46
    Originally posted by Serge View Post
    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.

    Comment


    • #47
      Originally posted by droidhacker View Post
      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...

      Comment


      • #48
        Originally posted by plonoma View Post
        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...

        Comment


        • #49
          Originally posted by droidhacker View Post
          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.

          Comment


          • #50
            Originally posted by droidhacker View Post
            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.
            Last edited by Serge; 09-19-2013, 11:03 AM.

            Comment


            • #51
              Originally posted by TheOne View Post
              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.

              Comment

              Working...
              X