Thread (3 messages) flat view 3 messages, 2 authors, 2011-06-20

Re: Framebuffer driver for controller with indirect addressing?

From: Steve Strobel <hidden>
Date: 2011-06-20 21:02:36

At 06:18 PM 6/17/2011, Bernie Thompson wrote:
On Fri, Jun 17, 2011 at 4:10 PM, Steve Strobel
[off-list ref] wrote:
quoted
It does not have address lines, so the framebuffer memory
is not directly accessible

If someone could point me to a driver that works in a similar way, it would
help me out a lot. Â Thanks.
Hi Steve - there are several drivers that handle this kind of case,
including the udlfb driver for DisplayLink USB graphics chips (in the
kernel tree /drivers/video/udlfb.c)
That helps a lot.  I will check it out.  Is there 
something other than the source code that I 
should read to get up to speed on it?
The main unsolved challenge is fbdev (in the memory mapped framebuffer
case) assumes writes to the framebuffer take effect immediately.  [snip]
If I am understanding you right, the challenge is 
knowing when to flush the changed framebuffer memory to the graphics hardware.
1) Use of /driver/video/fb_defio.c to use the MMU to trigger...
I don't know if a Blackfin system could support 
that method or not.  It doesn't have a full MMU 
with virtual memory (it runs uClinux), but it 
does have a memory protection unit.  I suppose 
all that would be needed is to be notified when 
the framebuffer memory is written to;  I think it could do that.
2) Use of an ioctl to allow the user mode client to inform the
framebuffer of changed pixels (usually xorg forwarding X DAMAGE
notifications, which are well matched for this purpose).  This works
well and is simple, however we don't yet have a standardized ioctl, so
several drivers have different ioctls and thus custom x servers,
instead of being supported by the standard xf86-video-fbdev driver.
Since this is a custom embedded system, we are in 
control of all of the software on it.  So we can 
just make sure that everything included is set up for the same ioctl.
#2 would be the quickest way to give Linux a clean way of handling
remote (non-directly-addressable) framebuffers.

Others may have some additional suggestions.
Someone suggested to me using the double-buffer 
flipping logic.  Does it get flipped on every 
screen refresh, or just when the contents of one buffer have been changed?
Hope that helps. Best wishes,
Bernie
http://plugable.com/
Thanks a bunch,
Steve



---
Steve Strobel
Link Communications, Inc.
1035 Cerise Rd
Billings, MT 59101-7378
(406) 245-5002 ext 102
(406) 245-4889 (fax)
WWW: http://www.link-comm.com
MailTo:steve.strobel@link-comm.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help