The instructions were provided here http://www.raspberrypi.org/phpBB3/viewt ... 17#p467617jamesh wrote:Is there any way of turning this on and off so I can do easy comparisons.
jamesh wrote:Is there any way of turning this on and off so I can do easy comparisons.
Had a quick play - looks pretty snappy!
asb wrote:... get rid of /usr/share/X11/xorg.conf.d/99-fbturbo.conf
Doh! Missed the disable instructions as I read the install instructions. Ta.ssvb wrote:The instructions were provided here http://www.raspberrypi.org/phpBB3/viewt ... 17#p467617jamesh wrote:Is there any way of turning this on and off so I can do easy comparisons.
Or just edit the config file (/usr/share/X11/xorg.conf.d/99-fbturbo.conf) to change between "fbdev" and "fbturbo", reboot and check /var/log/Xorg.0.log to confirm which driver got really loaded.
Can it be added to the Jessie repo?asb wrote:I've packaged up fbturbo, and you can now install it from the Foundation's Raspbian repo with
Code: Select all
sudo apt-get update && sudo apt-get install xserver-xorg-video-fbturbo
This may be a strange question, but do you get a non-blank window with the standard fbdev driver? If the answer is "yes" and we have a regression here, then there are a number of options to try tweaking (they should be all described in "man fbturbo"). If any of these options happens to fix/workaround the problem, please let me know.dliloch wrote:When I use tightvncserver I only get a blank window with my vnc client.
Do I have to do something special to make this work with the fb turbo?
Had a chance to try this tonight, and it does feel more responsive.blachanc wrote:Anyway: To answer your question directly: yes, I do care a lot about speed.ssvb wrote:
Of course everything depends on whether the Raspberry Pi users are interested in a faster X11 desktop or not. So far it looks like nobody cares, and the community is just waiting for a wayland silver bullet to save the day. Which is of course also fine, and means less work for me to do
And a big Thank you for your work!!!
(and another thread to subscribe to)
Tried it - Ugly redraw trail is indeed gone. A definite improvement- nice work!ssvb wrote:Dragging windows should be happening without an ugly redraw trail. That's the performance issue which is specifically addressed.
Well, the screenshots from the Web browser beta announcement message don't show any traces of wayland/weston yet, so I guess it indeed should work fine with fbturbo. Please note that compared to the fbdev driver, fbturbo removes one redundant intermediate buffer copy (the shadow layer), and has nearly the same speed as the direct access to the framebuffer for many practical use cases (XShmPutImage should have roughly the same performance as memcpy from some offscreen buffer to the framebuffer). So you should also have faster browsing when compared to the regular fbdev driver.andrum99 wrote:I've just tested this with the new web browser called "web" that the foundation has just released - seems to co-exist quite happily - yay!
I believe the initial "Web" video decode plan is for the hw acceleration layer to produce to sequence of RGB frames of the requested size that will be composited in the normal way by X. This isn't the most efficient way, but should be fine for typical YouTube videos, and should be compatible with other software (like fbturbo or VNC).ssvb wrote: Assuming that Web is currently X11 based, I still wonder about the current HTML5 video hardware acceleration details. Does it use dispmanx to do roughly the same hackish hardware video decoding integration with X11 window system as libvdpau-sunxi (basically setting up a display controller layer with color key from the application process and trying to make sure that it is correctly positioned)?