lkml.org 
[lkml]   [2003]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: Help with patch for vesafbd support again?
From
> 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.

Hi,

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)?

Thanks,
~Randy



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:34    [W:0.058 / U:0.872 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site