WM8505 video acceleration
Angus Gratton
reverse engineering the video acceleration on the WM8505 kernel. Even
with the kernel sources, I'm finding it slow going - mostly (I think)
because I have no background in video hardware so I don't really know
what I'm looking at. Also due to the aforementioned lack of
documentation.
The VT8500 datasheet has documentation of the video registers, but it
looks like this was expanded a fair bit for WM8505 and no
documentation has appeared.
The WM8505 has three different framebuffer video components in the
source - GE, VFP and VPP(*). The default fb0 is the GE framebuffer,
and this works fine for simple access.
Android enables double buffering via framebuffer pan_display. If you
boot a standard Android distribution against Wondermedia's WM8505
kernel then the video modes don't get set properly up and you get four
flickery copies of the display.
Reverse-engineering the calls that the modified Android 1.6 makes, it
seems like Android maps the vfp memory space (fb1), it must write some
values directly there, then makes some ioctl calls to VPP in order to
set up the rest of the video state. However, after this initialisation
it looks to me like the GE framebuffer is used with normal pan_display
page flipping while Android is actually running.
If anyone is interesting in collaborating on this then I can provide
some debugging patches, log dumps and my current understanding of the
initialisation sequence. Otherwise I'll keep at it when I have time
and muddle it out.
(*) I've had trouble finding any non-trivial reference materials for
these terms. Are they standard concepts? Can anyone recommend a good
resource for learning about design of video hardware?
edo1
I think simple framebuffer is sufficient to me.
Angus Gratton
> I will run debian on wm8505 netbook.
> I think simple framebuffer is sufficient to me.
I agree, you're entirely right for normal Debian usage. Have you seen
how it works with video playback or animation/games?
The catch is that Android requires double buffering support at a
minimum, so to get a kernel that's capable of running an unmodifed
Android we need to work out the video modes.
- Angus
abrasive
> source - GE, VFP and VPP(*). The default fb0 is the GE framebuffer,
> and this works fine for simple access.
the 8500's in some detail.
I have a strong suspicion that the "VPP" handles the onboard VGA port
(which I've never seen used). Video Processing mumble mumble.
abrasive
No.
As an aside:
08:33 nextvolum> the graphic engine is designed for Windows CE
08:33 nextvolum> in fact the raster operation codes are the same
Windows CE uses.
08:35 nextvolum> I also reverse engineered some object files from the
wm8435 tree to see that.
08:35 nextvolum> and they used the windows ce rop codes
Алексей Чарков
> some debugging patches, log dumps and my current understanding of the
> initialisation sequence. Otherwise I'll keep at it when I have time
> and muddle it out.
(0xd8050300-0xd8050f00) from U-boot? I have already written a simple
non-accelerated framebuffer driver for VT8500, and it at least draws
Tux fine :) Graphics Engine (GE) is what provides acceleration for
raster operations, and it is identical between VT8500 and WM8505 (to
my understanding). Most likely, there is something similar to VT8500's
LCDC in WM8505, but at a different location :)
Alexey Charkov
(whatever that stands for), which is at 0xd8050300-0xd80503ff. Offsets
are defined in drivers/video/wmt/register/wm8510/wm8510-govw-reg.h.
Could be a good place to start :)
edo1
> Angus, could you please dump memory around some relevant registers
> (0xd8050300-0xd8050f00) from U-boot?
d8050300: 00000000 00000000 00000000 00000000 ................
d8050310: 00000000 00000000 00000000 00000000 ................
d8050320: 00000000 00000000 04000400 04000400 ................
d8050330: 00000000 00000000 00000000 00000000 ................
d8050340: 00000000 00000000 00000000 000f0000 ................
d8050350: 00000000 00000000 00000000 00000000 ................
d8050360: 00000000 00000000 00000000 00000000 ................
d8050370: 00000000 00000000 00000000 00000000 ................
d8050380: 00000000 00000000 00000000 00000000 ................
d8050390: 00000000 00000000 00000000 00000000 ................
d80503a0: 00000000 00000000 00000000 00000000 ................
d80503b0: 00000000 00000000 00000000 00000000 ................
d80503c0: 00000000 00000000 00000000 00000000 ................
d80503d0: 00000000 00000000 00000000 00000000 ................
d80503e0: 00000000 00000000 00000000 00000000 ................
d80503f0: 00000000 00000000 00000000 00000000 ................
You need more?
Alexey Charkov
use display like it does on 8500, does it?
What about the same registers under Android kernel then?:)
2010/8/23, edo1 <edo...@gmail.com>:
Ed Spiridonov
Ok, that's not too informative:) I presume, U-boot on 8505 does not
use display like it does on 8500, does it?
U-boot my netbook show logo on boot:
show logo .....
LCD param (setting): 1,30000,8,800,480,48,40,40,3,29,13
PWM param (setting): 0,25,100,90,98,38,8,0,27
LCD FrameBuffer = 0x07600000, BMP Address = 0x03C00000
Loading BMP ..... ok
Ed Spiridonov
Ok, that's not too informative:) I presume, U-boot on 8505 does not
use display like it does on 8500, does it?
What about the same registers under Android kernel then?:)
from gefb_probe():
d8050300: 00 00 00 00 80 00 00 00 01 00 00 00 00 00 00 00
d8050310: 00 00 00 00 00 00 00 00 00 00 00 00 1f 00 00 00
d8050320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d8050330: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d8050340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d8050350: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d8050360: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d8050370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d8050380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d8050390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d80503a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d80503b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d80503c0: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d80503d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d80503e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d80503f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Angus Gratton
> 2010/8/24 Alexey Charkov <alc...@gmail.com>
> What about the same registers under Android kernel then?:)
>
> from gefb_probe():
> d8050300: 00 00 00 00 80 00 00 00 01 00 00 00 00 00 00 00
FWIW I threw together a little program to dump registers via /dev/mem
and ran it on all of the video-related addresses I could think of: under
Debian (with X11 running via the simple GE framebuffer), under Android
(with VPP fanciness) and again under Android once the display had gone
to sleep.
The GOVW register range is the same under Debian and Android (and same
as Ed saw, above) but the other regions have lots of differences. :)
I haven't had time to work anything out from the results yet (did you
make sense of anything in Ed's dump, Alexey?) but thought it might be of
interest.
Files (output, source, program, dump script) all up at
http://projectgus.com/files/eken/memdump/
Cheers,
Angus
PS The reason I didn't just dump the entire I/O memory area is that some
reserved areas seem to cause the process to segfault on read. :).
PPS These are all doing single byte reads. Not sure whether these IO
areas are read-size-sensitive, might check that over the weekend.
Alexey Charkov
it looks like it's the GE Alpha Mixer that is responsible for
outputting data to the display.
PS It should be safer to read unsigned longs from registers, to my
understanding.
2010/8/26, Angus Gratton <g...@projectgus.com>:
Alexey Charkov
possibly from U-boot as well)? Otherwise it looks quite strange :)
Angus Gratton
> Angus, could you please repeat the dumps with 32-bit read sizes (and
> possibly from U-boot as well)? Otherwise it looks quite strange :)
*facepalm* Yes, I must have been tired because I didn't even notice only
seeing non-zero values on the word boundaries. :)
Repeated with 32-bit reads, looks a bit better. Also dumped the same
areas from u-boot (I had to use the "manually align" feature in diffuse
to get a diff against the other dumps, but after that it worked out
well.)
Still at http://projectgus.com/files/eken/memdump/
(One interesting thing is there are two "screen on" dumps from Android,
that I think show the two sides of the page flip. Not 100% certain
though, it could be they are some other varying value.)
- Angus
edo1
> On Thu, 2010-08-26 at 10:48 -0700, Alexey Charkov wrote:
> > Angus, could you please repeat the dumps with 32-bit read sizes (and
> > possibly from U-boot as well)? Otherwise it looks quite strange :)
>
It looks like Android use YUV colorspace (?!?)
Can you dump 1MB-blocks at 0x07d00000 and at 0x05400000?
Angus Gratton
AFAIK Android should be using RGB565, provided the custom M001 version
hasn't made some very substantial changes.
Do you want me to dump memory while running Android, X11, or from
u-boot? Or all three?
(The following is from an off-list email but I thought I'd put them
on-list.)
> Nor now I think GOVR (and prorably GE acceleration) support is
> sufficient for fb console and X.org.
Yes, I think you're correct.
Do the registers in the VT8500 GE driver (as per Alexey's code) seem to
correspond to registers in the WM8505 at all?
> PS: why VIA use strange design with two fb devices and instead of
> pan_display function?
I don't know, it certainly looks very ad-hoc from what I can follow. My
guess is they may have implemented Android support using GE acceleration
only, and then hacked in VPP support afterwards from the userspace side,
instead of going back and reworking/recombining the kernel driver.
- Angus
Ed Spiridonov
> On Sat, 2010-09-11 at 08:44 -0700, edo1 wrote:
>> On Aug 28, 12:03 pm, Angus Gratton <g...@projectgus.com> wrote:
>> > On Thu, 2010-08-26 at 10:48 -0700, Alexey Charkov wrote:
>> > > Angus, could you please repeat the dumps with 32-bit read sizes (and
>> > > possibly from U-boot as well)? Otherwise it looks quite strange :)
>> >
>> > Still athttp://projectgus.com/files/eken/memdump/
>>
>> It looks like Android use YUV colorspace (?!?)
>> Can you dump 1MB-blocks at 0x07d00000 and at 0x05400000?
>
> AFAIK Android should be using RGB565, provided the custom M001 version
> hasn't made some very substantial changes.
But from your dump GOVR is in YUV mode (I may be mistaken of course).
And framebuffer address, used by GOVR (at 0xd8050890/0xd8050894)
differ from memory buffer, used by GE (at 0xd8050420/0xd805043c) and
from GE AMX buffer (at 0xd8050610/0xd8050614).
For now I'm not explored how GE AMX (GE alpha mixing) works.
> Do you want me to dump memory while running Android, X11, or from
> u-boot? Or all three?
from Android (I do not have Androd installed on my netbook)
> Do the registers in the VT8500 GE driver (as per Alexey's code) seem to
> correspond to registers in the WM8505 at all?
Yes, GE acceleration looks to be same on VT8500 and WM8505.
Ed Spiridonov
> On Sat, 2010-09-11 at 08:44 -0700, edo1 wrote:
>> It looks like Android use YUV colorspace (?!?)
>> Can you dump 1MB-blocks at 0x07d00000 and at 0x05400000?
>
> AFAIK Android should be using RGB565, provided the custom M001 version
> hasn't made some very substantial changes.
>> PS: why VIA use strange design with two fb devices and instead of
>> pan_display function?
>
> I don't know, it certainly looks very ad-hoc from what I can follow.
According to http://pdk.android.com/online-pdk/guide/display_drivers.html
Android makes two requirements of the driver: a linear address space
of mappable memory that it can write to directly and support for the
rgb_565 pixel format.
GOVR don't support 16bpp rgb, only 32bpp rgb (or YUV).
But GE AMX can support rgb565.
1. Is Android support imporant? Really Android can't work with 32bpp
framebuffer?
2. Is BPP (16/32) imporant for performance?
May be 16bpp is better for X server too?
Angus Gratton
On Sun, 2010-09-12 at 10:02 +0400, Ed Spiridonov wrote:
> But from your dump GOVR is in YUV mode (I may be mistaken of course).
Yes, you seem to be entirely right! I took a dump in Android of the 'vpp
framebuffer' at 0x5400000 and it seems to be YUV. Files are here:
http://projectgus.com/files/eken/fb-dumps/
The 0x5400000.pngs are the result of ImageMagick
convert -depth 32 -size 800x480 yuv:0x05400000.raw png:0x05400000.png
I'm guessing the slightly weird colours mean it is YUV but in a slightly
different colour space, or different subsampling? I played around a bit
but these things aren't my forte.
I couldn't just use dd if=/dev/mem to dump the GE framebuffer at
0x7d00000 (I assume because the VIA kernel dirtily sets mem= below that
offset and then addresses it directly.)
I did dump /dev/graphics/fb0 though, which I believe is the same memory
area. fbset on that device indicates that it's RGB565 format:
# fbset
mode "800x480-0"
# D: 0.033 MHz, H: 0.035 kHz, V: 0.066 Hz
geometry 800 480 800 960 16
timings 30000000 40 24 32 11 96 2
accel false
rgba 5/11,6/5,5/0,0/0
endmode
And it was. I expected it would be the boot screen, or whatever the last
displayed GE image was, but it was the same desktop image as the other
buffer.
fb0.png is the output from
fffmpeg -vcodec rawvideo -f rawvideo -pix_fmt rgb565 -s 800x400 -i fb0.raw -f image2 -vcodec png fb0.png
So that's interesting...
So I'm a bit confused as to what exactly could be going on here, either
the pixel values are being written independently as both RGB565 and YUV
to each buffer concurrently/redundantly, or a transparent process
(hardware or userspace) is converting the RGB565 values across from the
GE buffer to YUV in the VPP/GOVR buffer, which is then displayed on the
LCD.
I think probably the former - the people who patched Android were too
lazy to disable the default framebuffer driver, so it's still soldiering
on as RGB565 even though that buffer is not being used.
When I have more time I'll try some kernel-side code to read & write the
memory buffer contents, see what happens.
> > Do the registers in the VT8500 GE driver (as per Alexey's code) seem to
> > correspond to registers in the WM8505 at all?
>
> Yes, GE acceleration looks to be same on VT8500 and WM8505.
This is good news, at least. :).
On Sun, 2010-09-12 at 23:36 +0400, Ed Spiridonov wrote:
> According to http://pdk.android.com/online-pdk/guide/display_drivers.html
> Android makes two requirements of the driver: a linear address space
> of mappable memory that it can write to directly and support for the
> rgb_565 pixel format.
>
> GOVR don't support 16bpp rgb, only 32bpp rgb (or YUV).
> But GE AMX can support rgb565.
>
> 1. Is Android support imporant?
Android support is only important if you think it's important. :). I
think it would be good not to do anything that precludes adding Android
support, but I don't think that's likely to happen. It seems to me quite
possible that Android could run perfectly fine on a GE framebuffer
driver - AFAIK it just needs the two things you mention, plus
pan_display support to page flip. Nothing too complex there.
> Really Android can't work with 32bpp
> framebuffer?
Well, it seems from your investigations that it may work if someone (ala
Wondermedia) heavily patch the userspace Android libraries to make it
work, but I think it is otherwise hard-coded to set RGB565.
That also might possibly have changed in 2.x, the Android PDK documents
seem to date from before then.
>
> 2. Is BPP (16/32) important for performance?
> May be 16bpp is better for X server too?
Don't know much about this myself, probably depends on how much hardware
acceleration can be implemented in either video output type. Clearly
less bpp means less RAM overhead, FWIW. :).
I assume that if we use GE rather than VPP/GOVR then we'll get 16bpp
support anyhow, right? It's only the fancy mode that does not support
lower bpp?
- Angus
Alexey Charkov
> support anyhow, right? It's only the fancy mode that does not support
> lower bpp?
I personally believe that GE AMX is responsible for color space
expansion/transformation in this case. It is not capable of driving
output by itself, so it just converts what it gets from userspace to
what GOVR can handle.
With 32bpp GOVR-only ARGB we would have less memory overhead, as only
a single buffer would be needed. However, does xf86-video-fbdev
support 32bpp framebuffers? If Android does not, I would not be
surprised if fbdev does not either...
Ed Spiridonov
>> I assume that if we use GE rather than VPP/GOVR then we'll get 16bpp
>> support anyhow, right? It's only the fancy mode that does not support
>> lower bpp?
>
> I personally believe that GE AMX is responsible for color space
> expansion/transformation in this case. It is not capable of driving
> output by itself, so it just converts what it gets from userspace to
> what GOVR can handle.
Agree
edo1
> However, does xf86-video-fbdev
> support 32bpp framebuffers? If Android does not, I would not be
> surprised if fbdev does not either...
Ed Spiridonov
> Hi Ed,
>
>
> On Sun, 2010-09-12 at 10:02 +0400, Ed Spiridonov wrote:
>> But from your dump GOVR is in YUV mode (I may be mistaken of course).
>
> Yes, you seem to be entirely right! I took a dump in Android of the 'vpp
> framebuffer' at 0x5400000 and it seems to be YUV. Files are here:
>
> http://projectgus.com/files/eken/fb-dumps/
Yes, it is YUV.
I attach restored picture from your dump (bottom is b&w because
in-memory image size is over 1Mb).
Angus Gratton
> 2010/9/13 Angus Gratton <g...@projectgus.com>:
> > Yes, you seem to be entirely right! I took a dump in Android of the 'vpp
> > framebuffer' at 0x5400000 and it seems to be YUV. Files are here:
> >
> > http://projectgus.com/files/eken/fb-dumps/
>
> Yes, it is YUV.
> I attach restored picture from your dump (bottom is b&w because
> in-memory image size is over 1Mb).
Thanks Ed. Just for my own personal interest, what was the key to
decoding it correctly? Subsampling?
- Angus
Angus Gratton
On Mon, 2010-09-13 at 17:40 +0400, Alexey Charkov wrote:
> I personally believe that GE AMX is responsible for color space
> expansion/transformation in this case. It is not capable of driving
> output by itself, so it just converts what it gets from userspace to
> what GOVR can handle.
Sorry, I'm a bit slow on this. Is your theory that userspace can write
RGB data to the GE buffer, alpha channel transformation data (in some
format) to the AMX buffer, and the video hardware(?) will internally
generate 32-bit output suitable for GOVR? Or is it something more
intricate?
If I'm following you correctly, that would imply that the GE+GE AMX
support is a kind of backwards-compatibility layer between WM8505 and
VT8500, right? Because VT8500 doesn't have GOVR or GE AMX, am I correct?
- Angus
edo1
0x05400000 - offset of Y buffer, 0x05461800 - offset of UV buffer.
Ed Spiridonov
> Hi Alexey,
>
> On Mon, 2010-09-13 at 17:40 +0400, Alexey Charkov wrote:
>> I personally believe that GE AMX is responsible for color space
>> expansion/transformation in this case. It is not capable of driving
>> output by itself, so it just converts what it gets from userspace to
>> what GOVR can handle.
>
> Sorry, I'm a bit slow on this. Is your theory that userspace can write
> RGB data to the GE buffer, alpha channel transformation data (in some
> format) to the AMX buffer, and the video hardware(?) will internally
> generate 32-bit output suitable for GOVR?
nearly properly.
currently AMX convert RGB16 to YUV for GOVR.
> If I'm following you correctly, that would imply that the GE+GE AMX
> support is a kind of backwards-compatibility layer between WM8505 and
> VT8500, right? Because VT8500 doesn't have GOVR or GE AMX, am I correct?
according to pdf, VT8500 support GE AMX.
I think VT8500 LCDC is replaced by GOVR in WM8505, all other is similar.
Angus Gratton
> nearly properly.
> currently AMX convert RGB16 to YUV for GOVR.
>
I see now, that gels with the investigations I just did as well.
Writing to fb0 (assume GE) affects the Android display permanently until
the OS redraws.(*)
Writing to the GOVR framebuffer affects the Android display for a split
second, until the framebuffer redraws.
So it would seem that AMX is working exactly as you say, continuously
remapping the GE buffer into GOVR and translating RGB565->YUV.
Talking to a friend tonight about YUV framebuffers, I'm supposing the
existence of an AMX framebuffer-like region may be to "mask out" areas
of the screen so this process doesn't occur, allowing YUV overlays to be
written directly to the GOVR buffer. ?
**
Another interesting thing is that page flipping appears to be occurring
in GOVR.
d8050890: 05400000 05461800
d8050890: 05586000 055e7800
The equivalent addresses aren't changing in the GE registers, but I
assume two screens are being written there as well, and both are
translated to the GOVR buffer.
I can't come up with any explanation of why all this needs to be done in
software, rather than just using the GE framebuffer and RGB565. Do you
guys know?
Hth.
- Angus
(*) I still can't get /dev/mem to seek to the 0x7d00000 phys offset. 'dd
if=/dev/mem bs=1M skip=84 count=1' works to dump GOVR but swapping
'skip=125' yields "/dev/mem: Bad Address", any ideas why?
edo1
http://gitorious.org/linux-on-via-vt8500/vt8500-kernel/commit/cdb139e9e4c4e1afa9f6851445e59732547bd724
It is tested on netbook only.
Angus, can you test it on tablet?
Angus Gratton
Hey Ed,
Sorry for the delay. Framebuffer support shows up fine, Tux+fbconsole,
on both my WM8505 tablets (I have M001 & M003 now.) Well done!
One minor issue with the M003, this tablet has an 800x600 screen not
800x480 so at present the top 120 pixels wrap around to the bottom.
I'm not sure what the solution for that is. When I have time I will try
to dump memory and see if there's a way to detect the display type
(hence resolution) at boot time. Otherwise I guess that it needs to be a
kernel or boot parameter (I think that's how Wondermedia are currently
doing it.)
- Angus
Ed Spiridonov
> One minor issue with the M003, this tablet has an 800x600 screen not
> 800x480 so at present the top 120 pixels wrap around to the bottom.
You can change yres in arch/arm/mach-vt8500/wm8505_7in.c ;)
> I'm not sure what the solution for that is. When I have time I will try
> to dump memory and see if there's a way to detect the display type
> (hence resolution) at boot time.
u-boot set GOVR registers on startup.
It is possible to keep display size and timings, but is it right thing?
framebuffer driver set registers values now from scratch and (I hope)
will work without LCD support in bootloader (or with misconfigured
bootloader).
Alexey Charkov
> 2010/9/21 Angus Gratton <g...@projectgus.com>:
>> One minor issue with the M003, this tablet has an 800x600 screen not
>> 800x480 so at present the top 120 pixels wrap around to the bottom.
>
> You can change yres in arch/arm/mach-vt8500/wm8505_7in.c ;)
>
I believe that better yet would be to allow compile-time selection of
the default panel configuration via a Kconfig switch. I doubt that
there is any way to probe the attached display size at runtime from
the hardware itself.
Angus Gratton
> u-boot set GOVR registers on startup.
> It is possible to keep display size and timings, but is it right thing?
> framebuffer driver set registers values now from scratch and (I hope)
> will work without LCD support in bootloader (or with misconfigured
> bootloader).
I was thinking about this as well, but I think you're correct that
there's no guarantee that u-boot will be set right. For the tablets,
u-boot is reflashed during every firmware upgrade (a serious WTF in
itself) so it's quite easy to flash the wrong one.
I think Alexey's suggestion of a compile-time panel config is probably
the best one. At this time, I believe the only known configurations are
7in 800x480 and 8in 800x600. There is apparently a 10in 1024x600 in the
works.
Unlike Wondermedia, we can choose the luxury of being able to compile
different kernels for different devices. :)
- Angus
Alexey Charkov
accelerate a sizeable part of XRender through EXA using the GE Alpha
Mixing and ROP3 blitting operations, which should result in better
experience with any display other than fbcon (which is X). For that,
however, we'll need to add some userspace access interfaces (like a
bunch of custom ioctls, probably) and a custom accelerated version of
xf86-video-fbdev to hook into those interfaces.
Arnd, could you please comment whether such an extension could be
acceptable upstream, or should I give up the idea?
Any thoughts regarding this are welcome.
Alexey
Marius Cirsta
easier to implement than EXA ?
From what I've read the whole X Server thing is complicated and
besides with directFB you could run things without the overhead of the
X Server ( like QTE ) or you could just use DirectFB to run the X
Server on top of it as this is supported from what I understand.
Alexey Charkov
> I'm not an expert here but wouldn't directFB be better suited and
> easier to implement than EXA ?
>
Actually, judging by the docs, EXA seems to have quite a nice small
API. Furthermore, the issue of what to accelerate is up to userspace
code, as I would probably just export some accessors to GE controls
rather than implement the whole
compositing/blitting/transformation/whatever functions in kernel.
Personally I do not really like the idea of DirectFB, as it would
narrow down the set of applications that can make use of this
acceleration. I did not study it thoroughly, though, so this is open
to debate.
Marius Cirsta
If you think EXA is better go for that , the only thing is I was
thinking of not running the X Server and saving some RAM and resources
by accelerated rendering to the FB.
Arnd Bergmann
> Well I was thinking of using XDirectFB if needed but not my decision.
> If you think EXA is better go for that , the only thing is I was
> thinking of not running the X Server and saving some RAM and resources
> by accelerated rendering to the FB.
XDirectFB is essentially unmaintained, I wouldn't recommend using it
for new platforms. EXA and anything in the mainline X.org is much more
promising.
Arnd
Ed Spiridonov
> On Fri, 2010-09-17 at 08:09 -0700, edo1 wrote:
>> WM8505 framebuffer support is commited to Alexey's tree:
>> http://gitorious.org/linux-on-via-vt8500/vt8500-kernel/commit/cdb139e9e4c4e1afa9f6851445e59732547bd724
>>
>> It is tested on netbook only.
>>
>> Angus, can you test it on tablet?
>
> Hey Ed,
>
> Sorry for the delay. Framebuffer support shows up fine, Tux+fbconsole,
> on both my WM8505 tablets (I have M001 & M003 now.) Well done!
>
> One minor issue with the M003, this tablet has an 800x600 screen not
> 800x480 so at present the top 120 pixels wrap around to the bottom.
can you test current code with M003?
you must enable 800x600 panel on compile time; no autodetect there, sorry.
Angus Gratton
> can you test current code with M003?
> you must enable 800x600 panel on compile time; no autodetect there, sorry.
Seems good, boots to a full-screen console just fine. I like there being
an override option on the kernel command line, as well.
Cheers,
Angus