2006-01-03 22:39:38

by Thomas Koeller

[permalink] [raw]
Subject: [PATCH] non-linear frame buffer read/write access

While the code in fbmem.c allows for hooking read/write access
to non-linear frame buffers by means of fb_read and fb_write
in struct fb_ops, I could not find a way tho access the actual
frame buffer memory from within these routines. I therefore
had to patch fbmem.c, to be able to retrieve a pointer to
struct fb_info from the 'file' argument to these functions.

The second hunk of the patch is not strictly required, I only
did that for symmetry reasons (and the code is somewhat
shorter).

Patch is against 2.6.14

Signed-off-by: Thomas Koeller <[email protected]>

diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index e2667dd..145c18f 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -965,6 +965,7 @@ fb_open(struct inode *inode, struct file
return -ENODEV;
if (!try_module_get(info->fbops->owner))
return -ENODEV;
+ file->private_data = info;
if (info->fbops->fb_open) {
res = info->fbops->fb_open(info,1);
if (res)
@@ -976,11 +977,9 @@ fb_open(struct inode *inode, struct file
static int
fb_release(struct inode *inode, struct file *file)
{
- int fbidx = iminor(inode);
- struct fb_info *info;
+ struct fb_info * const info = (struct fb_info *) file->private_data;

lock_kernel();
- info = registered_fb[fbidx];
if (info->fbops->fb_release)
info->fbops->fb_release(info,1);
module_put(info->fbops->owner);

--
Thomas Koeller
thomas at koeller dot dyndns dot org


2006-01-08 00:54:55

by Antonino A. Daplas

[permalink] [raw]
Subject: Re: [PATCH] non-linear frame buffer read/write access

Thomas Koeller wrote:
> While the code in fbmem.c allows for hooking read/write access
> to non-linear frame buffers by means of fb_read and fb_write
> in struct fb_ops, I could not find a way tho access the actual
> frame buffer memory from within these routines. I therefore
> had to patch fbmem.c, to be able to retrieve a pointer to
> struct fb_info from the 'file' argument to these functions.
>
> The second hunk of the patch is not strictly required, I only
> did that for symmetry reasons (and the code is somewhat
> shorter).
>
> Patch is against 2.6.14
>
> Signed-off-by: Thomas Koeller <[email protected]>

Okay.

Tony