Page 4 of 4

Re: Experimental enhanced X driver (rpifb)

Posted: Thu Dec 26, 2013 2:01 pm
by ssvb
portets wrote:Will this also speed up XWayland?
I don't think so. Because fbturbo for most part just removes extra overhead related to windows handling, and this is the area taken over by wayland.
Just wondering if this work is forward-compatible.
More like it only sets the performance baseline for xwayland. To make sure that wayland developers don't deliver something that performs worse.

Re: Experimental enhanced X driver (rpifb)

Posted: Fri Dec 27, 2013 10:47 am
by texy
Hi,
I see that fbturbo is now enable by default in the latest raspbian download. 2 issues :

Code: Select all

FATAL: Module g2d_23 not found.
is now displayed during the startx load up sequence - this may or may not be a real issue.
Another problem I have is that I cannot use my display boards that utilise fb1 showing X11 using the command

Code: Select all

FRAMEBUFFER=/dev/fb1 startx -- -dpi 60
.
Is there an equivalent fbturbo command to use fb1 ?

If I remove or rename the /usr/share/X11/xorg.conf.d/99-fbturbo.conf file both issues disappear.
Texy

Re: Experimental enhanced X driver (rpifb)

Posted: Fri Dec 27, 2013 11:34 am
by asb
texy wrote:Hi,
I see that fbturbo is now enable by default in the latest raspbian download. 2 issues :

Code: Select all

FATAL: Module g2d_23 not found.
is now displayed during the startx load up sequence - this may or may not be a real issue.
This is not a real issue, it's just checking for the module used for AllWinner devices.

Re: Experimental enhanced X driver (rpifb)

Posted: Fri Dec 27, 2013 5:53 pm
by pdawg17
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
fbturbo should be used by default when you startx. If in doubt, check /var/log/Xorg.0.log. If you wish to disable fbturbo, then either apt-get remove xserver-xorg-video-fbturbo or get rid of /usr/share/X11/xorg.conf.d/99-fbturbo.conf. I'm particularly interested in any regressions - is there anything that seems slower than before, or fails to render correctly.

Thanks again for all your work on this, ssvb.
When I try to apt-get fbturbo I get "E: Unable to locate package xserver-xorg-video-fbturbo". Is that still the correct place to find it?

Broken dependency on Jessie

Posted: Fri Dec 27, 2013 6:13 pm
by AaronP
xserver-xorg-video-fbturbo on Raspbian Jessie has a broken dependency: xorg-video-abi-12

Any workarounds?

Re: Experimental enhanced X driver (rpifb)

Posted: Fri Dec 27, 2013 6:51 pm
by cc_benny
pdawg17 wrote:When I try to apt-get fbturbo I get "E: Unable to locate package xserver-xorg-video-fbturbo". Is that still the correct place to find it?
Do you have the foundation repository configured? I have:

Code: Select all

deb http://archive.raspberrypi.org/debian wheezy main
deb-src http://archive.raspberrypi.org/debian wheezy main
in /etc/apt/sources.list.d/rpi-foundation.list

Re: Experimental enhanced X driver (rpifb)

Posted: Sat Dec 28, 2013 1:34 pm
by ssvb
texy wrote: Another problem I have is that I cannot use my display boards that utilise fb1 showing X11 using the command

Code: Select all

FRAMEBUFFER=/dev/fb1 startx -- -dpi 60
.
Is there an equivalent fbturbo command to use fb1 ?

If I remove or rename the /usr/share/X11/xorg.conf.d/99-fbturbo.conf file both issues disappear.
Texy
You can edit /usr/share/X11/xorg.conf.d/99-fbturbo.conf and change /dev/fb0 to /dev/fb1 there. Or remove that line altogether to see if the value from the FRAMEBUFFER environment variable gets picked up.

Re: Experimental enhanced X driver (rpifb)

Posted: Sun Dec 29, 2013 10:51 am
by texy
ssvb wrote:
texy wrote: Another problem I have is that I cannot use my display boards that utilise fb1 showing X11 using the command

Code: Select all

FRAMEBUFFER=/dev/fb1 startx -- -dpi 60
.
Is there an equivalent fbturbo command to use fb1 ?

If I remove or rename the /usr/share/X11/xorg.conf.d/99-fbturbo.conf file both issues disappear.
Texy
You can edit /usr/share/X11/xorg.conf.d/99-fbturbo.conf and change /dev/fb0 to /dev/fb1 there. Or remove that line altogether to see if the value from the FRAMEBUFFER environment variable gets picked up.
Thankyou.
By #'ing out

Code: Select all

Option          "fbdev" "/dev/fb0"
allows startx to be used as normal to hdmi, and also allows

Code: Select all

FRAMEBUFFER=/dev/fb1 startx -- -dpi 60
to be used with fb1 devices ;)
Texy

Re: Experimental enhanced X driver (rpifb)

Posted: Sun Dec 29, 2013 1:09 pm
by dliloch
ssvb wrote:After/if we patch the kernel and add IRQ support to wait for DMA copy completion instead of spinning, the CPU usage should drop quite significantly when moving windows.
just a question .. in noobs 1.3.3. just out did they put in the IRQ supoort? ..

Re: Experimental enhanced X driver (rpifb)

Posted: Sun Dec 29, 2013 6:36 pm
by bleep42
Hi ssvb & hglm.
Thanks for all your hard work :-) I've installed your driver on a standard install of Raspbian and can definitely see a speed improvement, especially to dragging windows around. I was one of the people who was testing Simons Accelerated X driver, so I've reproduced some of the scenarios that produced problems for his driver to see if yours was ok and it is fine :-)
The only very minor thing I've found so far is if I load a large (2300x1800) image into the standard 'image viewer' that comes with Raspbian and tell it to display 'original size' the window will only show the top left corner of the image, it doesn't matter where you drag the sliders to, you will only get the top left corner, if you increase or decrease the image size using the '+' or '-' buttons, ie to 95% or 105% it works perfectly, it only seems to affect it at 100%. I haven't been able to go back to the original driver yet to check that it isn't a problem with 'image viewer' itself, I'll report back. Forget that :-) it does it with the old X driver as well :-)
I've been doing more playing and it definitely improves all the browsers I've tried ('Web', Chromium, Midori) they all scroll smoother/faster, especially if there are lots of images, like say an Ebay page.
Thanks again for all your excellent work on this driver, do you think any of your 'low hanging fruits' from your round up will also get incorporated, to make it even better. :-)
Regards, Kevin.

Re: Experimental enhanced X driver (rpifb)

Posted: Thu Jan 02, 2014 1:05 pm
by jamesh
dliloch wrote:
ssvb wrote:After/if we patch the kernel and add IRQ support to wait for DMA copy completion instead of spinning, the CPU usage should drop quite significantly when moving windows.
just a question .. in noobs 1.3.3. just out did they put in the IRQ supoort? ..
I don' think so - see here... http://www.raspberrypi.org/forum/viewto ... 77#p478877

Re: Experimental enhanced X driver (rpifb)

Posted: Thu Jan 02, 2014 7:54 pm
by ssvb
bleep42 wrote:Thanks again for all your excellent work on this driver, do you think any of your 'low hanging fruits' from your round up will also get incorporated, to make it even better. :-)
It's not difficult, but needs a bit of time. And I just don't have much free time lately. But luckily, other people have also started looking into improving things. See the forum thread referenced by jamesh :-)

Re: Experimental enhanced X driver (rpifb)

Posted: Thu Jan 02, 2014 10:14 pm
by jamesh
Just out of interest, where would I look if I wanted to see how difficult it would be to add the HW cursor? That seems pretty low hanging - just a small dispmanx bitmap to stuff out. Slightly more convoluted when it need to change, but doesn't seem too onerous. But I have no idea where to look.

Re: Experimental enhanced X driver (rpifb)

Posted: Thu Jan 02, 2014 10:42 pm
by jamesh
Ah, would it be the cursor function in here ?

http://lxr.free-electrons.com/source/in ... /fb.h#L236

and code woudl go in here

https://github.com/JamesH65/linux/blob/ ... m2708_fb.c

Re: Experimental enhanced X driver (rpifb)

Posted: Thu Jan 02, 2014 11:00 pm
by oldnpastit
I think for h/w cursor support you need to modify the X11 server module, xf86-video-fbturbo. Look at sunxi_disp_hwcursor.c.

EDIT: that doesn't seem to make use of the ioctl() though, which would surely be the right thing to do.

Re: Experimental enhanced X driver (rpifb)

Posted: Thu Jan 02, 2014 11:23 pm
by jamesh
Looking at the standard fb driver, it's all calls for the HW cursor, no ioctls.

Not sure how that relates to the sunxi stuff - need to clone it and have a good search through to see the path through - I presume it must, at the core, use the standard FB interface, which seems straightforward.

Anyway, bedtime. Spent all evening getting nowhere with my tax return - I think a call to HMRC is in order. Even digging through Linux FB drives was more fun.

Re: Experimental enhanced X driver (rpifb)

Posted: Thu Jan 09, 2014 8:08 am
by ssvb
jamesh wrote:Just out of interest, where would I look if I wanted to see how difficult it would be to add the HW cursor? That seems pretty low hanging - just a small dispmanx bitmap to stuff out. Slightly more convoluted when it need to change, but doesn't seem too onerous. But I have no idea where to look.
The relevant Xorg documentation is here:
http://cgit.freedesktop.org/xorg/xserve ... ver-1.15.0
http://www.x.org/releases/X11R7.7/doc/x ... esign.html

The X-specific part of the hardware cursor implementation in fbturbo for sunxi hardware is here: https://github.com/ssvb/xf86-video-fbtu ... hwcursor.c
It uses lightweight wrappers for sunxi-specific kernel ioctls (functions like 'sunxi_hw_cursor_show', 'sunxi_hw_cursor_hide', 'sunxi_hw_cursor_set_position', 'sunxi_hw_cursor_load_palette', ...) which are implemented in another source file. Basically, something similar needs to be added for Raspberry Pi DispmanX cursor. The test for DispmanX can be added to configure to make sure that the newly added code does not break build for the other platforms.

There is also a somewhat messy fbturbo fork, which hacks support for rockchip hardware into it: https://github.com/olegk0/xf86-video-fbdev
That's not how I want things to be done, but you still may have a look.

Re: Experimental enhanced X driver (rpifb)

Posted: Thu Jan 09, 2014 8:15 am
by ssvb
jamesh wrote:Ah, would it be the cursor function in here ?

http://lxr.free-electrons.com/source/in ... /fb.h#L236

and code woudl go in here

https://github.com/JamesH65/linux/blob/ ... m2708_fb.c
We don't strictly need to use the standard kernel fbdev ioctls in fbturbo and may directly go for DispmanX userland API instead. The fb_copyarea was a bit special case, because it was also useful for accelerating scrolling in the framebuffer console even without X.

Re: Experimental enhanced X driver (rpifb)

Posted: Thu Jan 09, 2014 9:28 am
by jamesh
I've had no time to look at this due to real work getting inthe way. General idea after discussions is to add new mailbox command(s) for HW cursor, add some code to handle them on the GPU, and plumb that in to the X driver (or the FB driver I suppose since mailboxes work OK in the kernel).

But no chance to investigate for the next few days at least.

Re: Experimental enhanced X driver (rpifb)

Posted: Fri Jan 10, 2014 9:18 pm
by mstevetodd
dliloch wrote:my bad... I completely removed tightvncserver then reinstalled and all is ok .. there must have been something I was doing previously with my config of xstartup in the .vnc directory .. by completely removing and reinstalling tightvncserver that seems to have "fixed" it... sorry
-don
Thanks for this note. I also had to remove and reinstall tightvncserver before vncserver would start.
--SteveT

Re: Experimental enhanced X driver (rpifb)

Posted: Tue Jan 14, 2014 8:01 pm
by ssvb
jamesh wrote:General idea after discussions is to add new mailbox command(s) for HW cursor, add some code to handle them on the GPU, and plumb that in to the X driver (or the FB driver I suppose since mailboxes work OK in the kernel).
Very nice. Having the hardware cursor feature as a first class citizen is even better.

Re: Experimental enhanced X driver (rpifb)

Posted: Wed Jan 15, 2014 9:35 am
by jamesh
I've got it to display a cursor, just need to plumb it in to the mailbox, then to fbturbo, but having trouble figuring out how the hell that mailbox stuff all works. Hopefully have something that moves cursors around (not necessarily under fbturbo control) by end of week, as do have actual work to do.

In general what image format does X use for cursors? I've used RGBA8888 internally for an example cursor, but I expect I'll have to do some translation at some point.

Re: Experimental enhanced X driver (rpifb)

Posted: Thu Jan 16, 2014 8:30 am
by ssvb
jamesh wrote:In general what image format does X use for cursors? I've used RGBA8888 internally for an example cursor, but I expect I'll have to do some translation at some point.
The cursors support quite a number of different formats, but you just tell the X server which one you want to use via a set of flags in xf86CursorInfoRec. However modern desktops such as gnome-shell and kde specifically want RGBA8888 cursors and the X server must support them too. This part is a bit tricky for the Allwinner hardware, because I'm handling RGBA8888 by reducing it to a 256 color palette. If Raspberry Pi has native RGBA8888 support for cursors, then this makes it even easier for you.

Re: Experimental enhanced X driver (rpifb)

Posted: Thu Jan 16, 2014 9:04 am
by jamesh
ssvb wrote:
jamesh wrote:In general what image format does X use for cursors? I've used RGBA8888 internally for an example cursor, but I expect I'll have to do some translation at some point.
The cursors support quite a number of different formats, but you just tell the X server which one you want to use via a set of flags in xf86CursorInfoRec. However modern desktops such as gnome-shell and kde specifically want RGBA8888 cursors and the X server must support them too. This part is a bit tricky for the Allwinner hardware, because I'm handling RGBA8888 by reducing it to a 256 color palette. If Raspberry Pi has native RGBA8888 support for cursors, then this makes it even easier for you.
I was checking out your sunxi HW cursor driver last night - I've half written a Raspi specific one - same structure but will call the raspi mailboxes to set the cursor. I've got it moving around OK, just need to test that to see if the whole process was worth it, then add the support to send the cursor bitmap to the GPU. Useful to know the bitmap formats - RGBA8888 is simple to support so will just use that one.