11 Oct, 2008

1 commit


31 Aug, 2008

1 commit


11 Jun, 2008

1 commit

  • This patch fixes several issues:
    Use the right openprom device name so the driver is actually loaded.
    Fix a crash due to unitialized info->pseudo_palette.
    Put the framebuffer in the proper mode for software rendering.
    checkpatch cleanups.

    Hardware acceleration was removed when the driver was rewritten
    for the new framebuffer API in 2003. Software rendering requires
    a different framebuffer access mode but that wasn't changed. The
    driver now works again but is slow. The proper fix is to reintroduce
    hardware acceleration.

    Signed-off-by: Robert Reif
    Signed-off-by: David S. Miller

    Robert Reif
     

09 May, 2008

1 commit


04 May, 2008

1 commit


28 Apr, 2008

1 commit


30 Jul, 2007

1 commit

  • All of these drivers use a silly:

    struct all_info {
    struct fb_info info;
    struct foo_par par;
    };

    struct all_info *all = kzalloc(sizeof(*all), GFP_KERNEL);
    all->info.par = &all->par;

    etc. etc. code sequence, basically replicating the provided
    framebuffer_alloc()/framebuffer_release(), and doing it badly.

    Not only is this massive code duplication, it also caused a
    bug in that we weren't setting the fb_info->device pointer
    which results in an OOPS when fb_is_primary_device() runs.

    Fix all of this by using framebuffer_{alloc,release}() and
    passing in "&of_device->dev" as the device pointer.

    Signed-off-by: David S. Miller

    David S. Miller
     

01 Jan, 2007

1 commit


30 Jun, 2006

1 commit


15 Jan, 2006

2 commits

  • No need for a file argument. If we'd really need it it's in vma->vm_file
    already. gbefb and sgivwfb used to set vma->vm_file to the file argument, but
    the kernel alrady did that.

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Antonino Daplas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Hellwig
     
  • The ioctl and file arguments to ->fb_mmap are totally unused and there's not
    reason a driver should need them.

    Also update the ->fb_compat_ioctl prototype to be the same as ->fb_mmap.

    Signed-off-by: Antonino Daplas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Hellwig
     

13 Dec, 2005

1 commit


13 Nov, 2005

1 commit

  • This patch adds a new function, sbusfb_compat_ioctl() to
    drivers/video/sbuslib.c and uses it as compat_ioctl in all sbus fb
    drivers

    This remove the last per-arch compat ioctl bits in
    arch/sparc64/kernel/ioctl32.c so it would be nice if people could test
    if this actually copiles and works and if yes apply it :)

    Signed-off-by: Christoph Hellwig
    Signed-off-by: David S. Miller

    Christoph Hellwig
     

07 Nov, 2005

1 commit

  • According to Jon Smirl, filling in the field fb_cursor with soft_cursor for
    drivers that do not support hardware cursors is redundant. The soft_cursor
    function is usable by all drivers because it is just a wrapper around
    fb_imageblit. And because soft_cursor is an fbcon-specific hook, the file is
    moved to the console directory.

    Thus, drivers that do not support hardware cursors can leave the fb_cursor
    field blank. For drivers that do, they can fill up this field with their own
    version.

    The end result is a smaller code size. And if the framebuffer console is not
    loaded, module/kernel size is also reduced because the soft_cursor module will
    also not be loaded.

    Signed-off-by: Antonino Daplas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Antonino A. Daplas
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds