Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 29

Thread: Raspberry Pi Gets New Wayland Weston Renderer

  1. #11
    Join Date
    Aug 2012
    Posts
    510

    Default

    So..... why are the wayland developers making a hardware specific backend for weston anyway? Is every arm board and intel and amd chip lines going to need specific backends for weston? What's the point in this?

  2. #12
    Join Date
    Jun 2009
    Posts
    582

    Default

    Quote Originally Posted by Kivada View Post
    Agreed, they should do a both a $50 model and a $100 dollar model, more options with better performance would draw in more people. Though I'd love to see them focus more on parts that can get fully OSS drivers.
    At $100 and above the appeal and the value of the Pi drops exponentially.

    If i'm going to pay a 3-figure sum for a low-powered computer I'd rather spend more on any aftermarket board with an x86 Atom processor that is only a little more power hungry than the Broadcom SoC used in the Pi but has superior processing power. Not to mention all of the benefits that come with the x86 stack such as a wider range of precompiled software available and Flash support.

  3. #13
    Join Date
    Oct 2008
    Location
    Finland
    Posts
    59

    Default

    Quote Originally Posted by dh04000 View Post
    So..... why are the wayland developers making a hardware specific backend for weston anyway? Is every arm board and intel and amd chip lines going to need specific backends for weston? What's the point in this?
    Because in this case it is the only way to support the hardware. It does not offer any of the standard Linux APIs. Instead, it has a unique proprietary API. If we want to use the device, we have to use that, since there is nothing else. And in this particular case, you can thank the Raspberry Pi Foundation for contracting us (Collabora) to do this, and supporting us while doing it. Otherwise, you would not be running Weston on the RPi in any usable speed.

    When hardware gets drivers into the Linux kernel and Mesa, or proprietary drivers supporting KMS, GBM, EGL, and GLESv2, we just use the Weston drm-backend with the GLESv2-renderer. That already covers practically all PC hardware.

    Also, using dispmanx for accelerating X would be so unimaginably painful, that it's practically not possible.

  4. #14
    Join Date
    Jul 2009
    Posts
    286

    Default

    Quote Originally Posted by pq__ View Post
    Because in this case it is the only way to support the hardware. It does not offer any of the standard Linux APIs.
    Which, right now, isn't possible for them to do because of the userspace code required to interface with the VideoCore. So it can't provide KMS.

    Quote Originally Posted by pq__ View Post
    Also, using dispmanx for accelerating X would be so unimaginably painful, that it's practically not possible.
    Entirely due to limitations in X's architecture.

  5. #15
    Join Date
    Jan 2012
    Posts
    117

    Default

    Quote Originally Posted by pq__ View Post
    Also, using dispmanx for accelerating X would be so unimaginably painful, that it's practically not possible.
    By accelerating X, do you mean X11 EGL support for GLESv2? Or RENDER acceleration? Or something else?

  6. #16
    Join Date
    Jul 2009
    Posts
    286

    Default

    Quote Originally Posted by ssvb View Post
    By accelerating X, do you mean X11 EGL support for GLESv2? Or RENDER acceleration? Or something else?
    He's talking about accelerating composition, rather than rendering. You can do that with GLES if you like, and then hand the server back a single flat image to display, but that ignores the massive dedicated 2D composition hardware in the VideoCore completely, and gives you a much higher system load. The only way you can do anything similar with X is to not use compositing, because only then does the server know what it should actually be displaying, and where. Except then you get jitter, you get flicker, and we've stepped back 15 years in the evolution of desktop graphics.

    The Weston backend hands the display hardware a list of every single visible surface, their stacking order, which transformation(s) should be applied, their position, and so on, and then the VideoCore displays it all with zero software intervention.

    This isn't RPi-specific, it's really common on ARM platforms, especially ones targeted towards set-top boxes, in-vehicle, etc.

  7. #17
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,921

    Default

    Quote Originally Posted by daniels View Post
    Which, right now, isn't possible for them to do because of the userspace code required to interface with the VideoCore. So it can't provide KMS.


    Entirely due to limitations in X's architecture.
    Heeey look who's back, hey Daniel.

    Quick wayland-related question. How's touchpad acceleration going? Or is still on the "TODO" List? I know you had a lot on your plate so no biggie, just curious.

  8. #18
    Join Date
    Jul 2009
    Posts
    286

    Default

    Quote Originally Posted by Ericg View Post
    Heeey look who's back, hey Daniel.

    Quick wayland-related question. How's touchpad acceleration going? Or is still on the "TODO" List? I know you had a lot on your plate so no biggie, just curious.
    Hi there! Still on the TODO list, I'm afraid.

    I just wrote a blog post about the RPi stuff with a little more detail though, so I hope that makes up for it. http://fooishbar.org/tell-me-about/w...-raspberry-pi/

  9. #19
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,921

    Default

    Quote Originally Posted by daniels View Post
    Hi there! Still on the TODO list, I'm afraid.

    I just wrote a blog post about the RPi stuff with a little more detail though, so I hope that makes up for it. http://fooishbar.org/tell-me-about/w...-raspberry-pi/
    Actually a very interesting read, so thanks for the heads-up. I didn't even realize you had your own blog though looking at it, it seems pretty new haha.

    Once the touchpad work goes (Sorry, laptop user :P So I care about it haha) is that Weston work or libwayland work? Meaning: will Kwin have to copy-paste / re-implement your work or will it be automatically available to them as long as they are using version x.y.z of libwayland?

  10. #20
    Join Date
    Jul 2009
    Posts
    286

    Default

    Quote Originally Posted by Ericg View Post
    Actually a very interesting read, so thanks for the heads-up. I didn't even realize you had your own blog though looking at it, it seems pretty new haha.
    Yep, my blog was dead for a good couple of years, only just resurrected it.

    Quote Originally Posted by Ericg View Post
    Once the touchpad work goes (Sorry, laptop user :P So I care about it haha) is that Weston work or libwayland work? Meaning: will Kwin have to copy-paste / re-implement your work or will it be automatically available to them as long as they are using version x.y.z of libwayland?
    The plan is to make it common for all environments - Weston, Shell, etc - but that's much easier said than done. It's pretty tricky, and just expressing the level of functionality people expect from touchpads is difficult. But I've high hopes of it happening in a reusable library fairly soon.

    And, no problem. I live on a laptop, with a touchpad and tap-to-click. Infuriating when it doesn't work, or is crap!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •