From: Andrew Clunis <orospakr@orospakr.is-a-geek.org>
To: linux-fbdev-devel@lists.sourceforge.net
Subject: Virtual Framebuffer on UM
Date: Sat, 10 Jul 2004 01:45:22 -0400 [thread overview]
Message-ID: <1089438322.3195.126.camel@localhost> (raw)
Hey, all!
I've been hacking on the UM kernel to reenable framebuffer support, in
preparation for writing a driver using SDL (http://libsdl.org). The
only things I have modified (at least with this tree, heh heh) so far
were to add 'source drivers/video/Kconfig' to arch/um's Kconfig, and
patch fbmem.c to disable caching on the UM arch. This is in the fb_mmap
function, in all those messy #ifdefs around the arch specific calls to
disable caching on the video memory.
I have a 2.6.6 UM kernel with the aforementioned patches that has been
booted with video=vfb:, and displays:
fb0: Virtual frame buffer device, using 1024K of video memory
in the kernel messages.
I've ensured /dev/fb0 device node has major 29 and minor 0.
However, when I do 'cp /dev/fb0 /root/blob', I get a file of size 0. I
was expecting a 1 meg file.
Is this normal behavior?
p.s. Geert, where can the source for your old GDK UM driver be found,
the one that had the -lpthread trouble? I have a design that will
(hopefully) not have those issues, but I'm curious as to how you tackled
the rest of it. (SDL itself has a -lpthread dependency, but I can get
around this. The graphical component of SDL does not require pthreads,
so as long as I don't init the audio or threading components, I should
be OK)
--
Regards,
Andrew Clunis
http://orospakr.is-a-geek.org/
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
next reply other threads:[~2004-07-10 5:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-10 5:45 Andrew Clunis [this message]
2004-07-10 15:05 ` Virtual Framebuffer on UM Geert Uytterhoeven
2004-07-11 3:46 ` Andrew Clunis
2004-07-11 8:01 ` Geert Uytterhoeven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1089438322.3195.126.camel@localhost \
--to=orospakr@orospakr.is-a-geek.org \
--cc=linux-fbdev-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.