Hi,
I've just stumbled upon a funny issue regarding FBIOGET_FSCREENINFO
ioctl command. What it does is filling in a structure called
fb_fix_screeninfo (fb.h) and passes it to userspace. Now the problem
is that if you run 32-bit userspace with a 64-bit kernel, you have
problems because of 2 unsigned long fields in the abovementioned
structure:
unsigned long smem_start; /* Start of frame buffer mem */
...
unsigned long mmio_start; /* Start of Memory Mapped I/O */
Most of the structure fields that follow smem_start get screwed from
32-bit userspace point.
I take it that applications somehow make use of these fields (at least
kdrive's fbdev does, from what I see).
Now the question is, how do we get around this situation?
--
I am free of all prejudices. I hate every one equally.
On 8/24/06, Alexander Shishkin <[email protected]> wrote:
> I've just stumbled upon a funny issue regarding FBIOGET_FSCREENINFO
To answer my own question. Now that I traced the codepaths of
compat_ioctl, I see that this particular problem has been worked
around by calling do_screeninfo_to_user() which resided in
fs/compat_ioctl.c (as of 2.6.14) and now moved to
drivers/video/fbmem.c where it actually belongs.
The problem in my case was my incorrect implementation of compat_ioctl
method in my driver that called filp->f_op->ioctl() for that matter.
Stupid me.
Just in case someone ever needs this.
--
I am free of all prejudices. I hate every one equally.