31 Jul, 2008

1 commit

  • Writes to the cmap fifo while the display is blanked caused cmap FIFO
    timeout messages and a wrong colormap. To avoid this the driver now
    maintains a colormap in memory and updates the colormap after the display
    is unblanked.

    Signed-off-by: Thomas Bogendoerfer
    Cc: Krzysztof Helt
    Cc: "Antonino A. Daplas"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Thomas Bogendoerfer
     

15 Nov, 2007

1 commit

  • Make 'default_mode' and 'default_var' be __initdata.
    Fixes these section warnings:

    WARNING: vmlinux.o(.data+0x128e0): Section mismatch: reference to .init.data:default_mode_CRT (between 'default_mode' and 'default_var')
    WARNING: vmlinux.o(.data+0x128e4): Section mismatch: reference to .init.data:default_var_CRT (between 'default_var' and 'dev_attr_size')

    Signed-off-by: Randy Dunlap
    Cc: "Antonino A. Daplas"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     

18 Jul, 2007

1 commit


01 Jul, 2006

1 commit


25 Feb, 2006

1 commit

  • The gbefb driver does not update the framebuffer layers visual setting when
    depth is changed with fbset, resulting in strange colors (very dark blue in
    16-bit, almost black in 24-bit).

    Signed-off-by: Kaj-Michael Lang
    Signed-off-by: Martin Michlmayr
    Signed-off-by: Antonino Daplas
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kaj-Michael Lang
     

18 Feb, 2006

1 commit

  • A sysfs function call uses the wrong parameter, and thus breaks a build on
    SGI O2.

    CC drivers/video/gbefb.o
    drivers/video/gbefb.c: In function ‘gbefb_remove’:
    drivers/video/gbefb.c:1246: error: ‘dev’ undeclared (first use in this function)
    drivers/video/gbefb.c:1246: error: (Each undeclared identifier is reported only once
    drivers/video/gbefb.c:1246: error: for each function it appears in.)
    make[2]: *** [drivers/video/gbefb.o] Error 1

    Signed-off-by: Joshua Kinard
    Signed-off-by: Antonino Daplas
    Signed-off-by: Martin Michlmayr
    Signed-off-by: Linus Torvalds

    Joshua Kinard
     

15 Jan, 2006

1 commit

  • 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
     

10 Nov, 2005

1 commit


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
     

06 Nov, 2005

1 commit

  • Statically allocated devices in module data is a potential cause
    of oopsen. The device may be in use by a userspace process, which
    will keep a reference to the device. If the module is unloaded,
    the module data will be freed. Subsequent use of the platform
    device will cause a kernel oops.

    Use generic platform device allocation/release code in modules.

    Signed-off-by: Russell King
    Acked-by: Greg Kroah-Hartman

    Russell King
     

31 Oct, 2005

1 commit


30 Oct, 2005

2 commits


21 Jun, 2005

1 commit


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