Re: Help with patch for vesafbd support again?
Tue, 18 Mar 2003 19:00:13 -0800 (PST)
> Hi Guys,
> Well I managed to finally dig up the old code that Aki Laukkanen deveoped
> sometime in early 2000. Unfortunately Aki died sometime in January 2001, so
> his work on the vesafbd daemon and patches to the vesafb device driver were
> lost - until now.
> I would like to revive this project, and the code I received from Matan
> Ziv-Av still configures and compiles correctly on Red Hat 8.0. I need to
> patch the latest kernel vesafb driver, but I think his patch is very old
> (probably around 2.2.14 timeframe). I am grabbing the 2.2.14 code to see if
> the patch will apply to that code, and then try to port the patch to the
> latest kernel release. Which brings up the first question. What kernel
> version should I patch against? 2.4.x or 2.5.x?
> However since I am not that familiar with the patching mechanism for the
> Linux kernel, would someone more familiar with this be willing to help out?
> I would like to modify the vesafb module in the kernel to optionally
> support the vesafbd daemon if it is present on the system, if not it will
> function as it does today. If vesafbd is present, it will be used to
> provide extended features to the default VESA framebuffer console driver.
> I would also like to generalise the daemon module a bit such that it does
> not need to be a VESA specific daemon, but could in fact contain it's own
> hardware interfacing module. For instance the daemon could use XFree86
> loadable driver modules to implement the functions rather than the VESA
> interface code, which would also open up the option of doing accelerated
> screen blits using the existing XFree86 driver modules. Hence I was
> thinking that the name 'vesafbd' for the daemon is a misnomer and should
> probably be changed to something else like 'fbcond' or something. Any
> suggestions? Or should we just leave it as 'vesafbd' even though it could
> be updated to support more than just the VESA BIOS interface?
> Also the code I have right now for the daemon relies on the /dev/vesafb
> special file to have been created, which is used as the communication
> mechanism between the modified vesafb kernel driver and the daemon code.
> The daemon simply constantly reads from /dev/vesafb for command packets to
> process and writes the results to /dev/vesafb. Some people suggested in the
> past that a better approach might be to either use extended ioctl()'s to
> the existing /dev/fb special file, and have the kernel module sleep until
> it needs to do something, or use other polling methods (of which I am not
> familiar). I would like some guidance here as to the best way to implement
> this daemon if people think it should be changed.
> Finally, before I embark on this project, will this patch will be accepted
> into the kernel source code tree? I would hate to spend my time on it only
> to find out that the kernel developers don't like it and won't accept it.
Can (will) you say *why* you want this? I can't find that info here.
and can you post the patch file (source code) that you have somewhere,
like a web page (not email if it's large)?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/