1. 23 Sep, 2009 1 commit
  2. 20 Sep, 2009 1 commit
  3. 11 Jun, 2009 1 commit
  4. 02 May, 2009 1 commit
  5. 06 Jan, 2009 1 commit
  6. 29 Dec, 2008 1 commit
    • Dave Airlie's avatar
      DRM: add mode setting support · f453ba04
      Dave Airlie authored
      Add mode setting support to the DRM layer.
      This is a fairly big chunk of work that allows DRM drivers to provide
      full output control and configuration capabilities to userspace.  It was
      motivated by several factors:
        - the fb layer's APIs aren't suited for anything but simple
        - coordination between the fb layer, DRM layer, and various userspace
          drivers is poor to non-existent (radeonfb excepted)
        - user level mode setting drivers makes displaying panic & oops
          messages more difficult
        - suspend/resume of graphics state is possible in many more
          configurations with kernel level support
      This commit just adds the core DRM part of the mode setting APIs.
      Driver specific commits using these new structure and APIs will follow.
      Co-authors: Jesse Barnes <jbarnes@virtuousgeek.org>, Jakob Bornecrantz <jakob@tungstengraphics.com>
      Contributors: Alan Hourihane <alanh@tungstengraphics.com>, Maarten Maathuis <madman2003@gmail.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
  7. 16 Oct, 2008 2 commits
  8. 14 Oct, 2008 1 commit
  9. 29 Apr, 2008 1 commit
    • Jan Engelhardt's avatar
      vt: fix background color on line feed · c9e587ab
      Jan Engelhardt authored
      A command that causes a line feed while a background color is active,
      such as
      	perl -e 'print "x" x 60, "\e[44m", "x" x 40, "\e[0m\n"'
      	perl -e 'print "x" x 40, "\e[44m\n", "x" x 40, "\e[0m\n"'
      causes the line that was started as a result of the line feed to be completely
      filled with the currently active background color instead of the default
      When scrolling, part of the current screen is memcpy'd/memmove'd to the new
      region, and the new line(s) that will appear as a result are cleared using
      memset.  However, the lines are cleared with vc->vc_video_erase_char, causing
      them to be colored with the currently active background color.  This is
      different from X11 terminal emulators which always paint the new lines with
      the default background color (e.g.  `xterm -bg black`).
      The clear operation (\e[1J and \e[2J) also use vc_video_erase_char, so a new
      vc->vc_scrl_erase_char is introduced with contains the erase character used
      for scrolling, which is built from vc->vc_def_color instead of vc->vc_color.
      Signed-off-by: default avatarJan Engelhardt <jengelh@computergmbh.de>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  10. 06 Feb, 2008 1 commit
  11. 17 Oct, 2007 2 commits
  12. 16 Oct, 2007 1 commit
    • Antonino A. Daplas's avatar
      vt/vgacon: Check if screen resize request comes from userspace · e400b6ec
      Antonino A. Daplas authored
      Various console drivers are able to resize the screen via the con_resize()
      hook.  This hook is also visible in userspace via the TIOCWINSZ, VT_RESIZE and
      VT_RESIZEX ioctl's.  One particular utility, SVGATextMode, expects that
      con_resize() of the VGA console will always return success even if the
      resulting screen is not compatible with the hardware.  However, this
      particular behavior of the VGA console, as reported in Kernel Bugzilla Bug
      7513, can cause undefined behavior if the user starts with a console size
      larger than 80x25.
      To work around this problem, add an extra parameter to con_resize().  This
      parameter is ignored by drivers except for vgacon.  If this parameter is
      non-zero, then the resize request came from a VT_RESIZE or VT_RESIZEX ioctl
      and vgacon will always return success.  If this parameter is zero, vgacon will
      return -EINVAL if the requested size is not compatible with the hardware.  The
      latter is the more correct behavior.
      With this change, SVGATextMode should still work correctly while in-kernel and
      stty resize calls can expect correct behavior from vgacon.
      Signed-off-by: default avatarAntonino Daplas <adaplas@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  13. 22 Jul, 2007 1 commit
  14. 17 May, 2007 1 commit
  15. 08 May, 2007 3 commits
  16. 02 May, 2007 1 commit
  17. 14 Feb, 2007 1 commit
    • Tim Schmielau's avatar
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      Tim Schmielau authored
      After Al Viro (finally) succeeded in removing the sched.h #include in module.h
      recently, it makes sense again to remove other superfluous sched.h includes.
      There are quite a lot of files which include it but don't actually need
      anything defined in there.  Presumably these includes were once needed for
      macros that used to live in sched.h, but moved to other header files in the
      course of cleaning it up.
      To ease the pain, this time I did not fiddle with any header files and only
      removed #includes from .c-files, which tend to cause less trouble.
      Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
      arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
      allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
      configs in arch/arm/configs on arm.  I also checked that no new warnings were
      introduced by the patch (actually, some warnings are removed that were emitted
      by unnecessarily included header files).
      Signed-off-by: default avatarTim Schmielau <tim@physik3.uni-rostock.de>
      Acked-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  18. 08 Dec, 2006 1 commit
  19. 10 Jul, 2006 2 commits
  20. 30 Jun, 2006 1 commit
  21. 27 Jun, 2006 1 commit
  22. 26 Jun, 2006 1 commit
    • Antonino A. Daplas's avatar
      [PATCH] Detaching fbcon: fix vgacon to allow retaking of the console · 50ec42ed
      Antonino A. Daplas authored
      One of the limitations of the framebuffer console system is its inablity to
      unload or detach itself from the console layer.  And once it loads, it also
      locks in framebuffer drivers preventing their unload. Although the con2fbmap
      utility does provide a means to unload individual drivers, it requires that at
      least one framebuffer driver is loaded for use by fbcon.
      With this change, it is possible to detach fbcon from the console layer. If it
      is detached, it will reattach the boot console driver (which is permanently
      loaded) back to the console layer so the system can continue to work.  As a
      consequence, fbcon will also decrement its reference count of individual
      framebuffer drivers, allowing all of these drivers to be unloaded even if
      fbcon is still loaded.
      Unless you use drivers that restores the display to text mode (rivafb and
      i810fb, for example), detaching fbcon does require assistance from userspace
      tools (ie, vbetools) for text mode to be restored completely.  Without the
      help of these tools, fbcon will leave the VGA console corrupted. The methods
      that can be used will be described in Documentation/fb/fbcon.txt.
      Because the vt layer also increments the module reference count for each
      console driver, fbcon cannot be directly unloaded.  It must be detached first
      prior to unload.
      Similarly, fbcon can be reattached to the console layer without having to
      reload the module.  A nice feature if fbcon is compiled statically.
      Attaching and detaching fbcon is done via sysfs attributes. A class device
      entry for fbcon is created in /sys/class/graphics. The two attributes that
      controls this feature are detach and attach. Two other attributes that are
      piggybacked under /sys/class/graphics/fb[n] that are fbcon-specific,
      'con_rotate' and 'con_rotate_all' are moved to fbcon.  They are renamed as
      'rotate' and 'rotate_all' respectively.
      Overall, this feature is a great help for developers working in the
      framebuffer or console layer.  There is not need to continually reboot the
      kernel for every small change. It is also useful for regular users who wants
      to choose between a graphical console or a text console without having to
      Example usage for x86:
      /* start in text mode */
      modprobe xxxfb
      modprobe fbcon
      /* graphical mode with fbcon using xxxfb */
      echo 1 > /sys/class/graphics/fbcon/detach
      /* back to text mode, will produce corrupt display unless vbetool is used */
      rmmod xxxfb
      modprobe yyyfb
      /* back to graphical mode with fbcon using yyyfb */
      Before trying out this feature, please read Documentation/fb/fbcon.txt.
      This patch:
      In order for fbcon to detach itself from the console layer, vgacon, which is a
      boot console driver, must be fixed so it can retake the console multiple
      times, not just during init.  The following needs to be done:
      - remove __init from the vgacon_startup, this is called again by
      - vc->rows and vc->cols are set manually by vgacon during init. After init,
        vc_resize() can be used
      - make sure the scrollback_buffer is not reallocated
      Signed-off-by: default avatarAntonino Daplas <adaplas@pol.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  23. 22 Jun, 2006 1 commit
    • Bjorn Helgaas's avatar
      [PATCH] vgacon: make VGA_MAP_MEM take size, remove extra use · 4f1bcaf0
      Bjorn Helgaas authored
      VGA_MAP_MEM translates to ioremap() on some architectures.  It makes sense
      to do this to vga_vram_base, because we're going to access memory between
      vga_vram_base and vga_vram_end.
      But it doesn't really make sense to map starting at vga_vram_end, because
      we aren't going to access memory starting there.  On ia64, which always has
      to be different, ioremapping vga_vram_end gives you something completely
      incompatible with ioremapped vga_vram_start, so vga_vram_size ends up being
      As a bonus, we often know the size up front, so we can use ioremap()
      correctly, rather than giving it a zero size.
      Signed-off-by: default avatarBjorn Helgaas <bjorn.helgaas@hp.com>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  24. 27 Mar, 2006 2 commits
  25. 24 Feb, 2006 1 commit
  26. 09 Jan, 2006 2 commits
  27. 22 Nov, 2005 1 commit
    • Antonino A. Daplas's avatar
      [PATCH] vgacon: Fix usage of stale height value on vc initialization · 5ef897c7
      Antonino A. Daplas authored
      Reported by: Wayne E. Harlan
      "[1.] One line summary of the problem:
      When the kernel option "vga=1" is used, additional tty's (alt+control+Fx
      with x=2,3,4,5, etc) do not provide the full 50 lines of output.  The first
      one does have 50 lines, however.
      [2.] Full description of the problem/report:
      These addtitional tty's show only 39 lines plus the top pixel of the 40-th
      line.  The remaining lines are black and not shown.  Kernel version does not show this problem."
      This bug is caused by using a stale font height value on vgacon_init.
      Booting with vga=1 gives an 80x50 screen with an 8x8 font.  Somewhere
      during the initialization, the font was changed to 8x9 and the first
      vc was correctly resized to 80x44.  However, the rest of the vc's were
      not allocated yet, and when they were subsequently initialized, they
      still used a font height of 8 (instead of 9) causing the mentioned bug.
      Fix by saving the new font height to vga_video_font_height.
      Signed-off-by: default avatarAntonino Daplas <adaplas@pol.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  28. 05 Nov, 2005 1 commit
    • Samuel Thibault's avatar
      [PATCH] Set the vga cursor even when hidden · 88dcb6c4
      Samuel Thibault authored
      Some visually impaired people use hardware devices which directly read
      the vga screen. When newt for instance asks to hide the cursor for
      better visual aspect, the kernel puts the vga cursor out of the screen,
      so that the cursor position can't be read by the hardware device. This
      is a great loss for such people.
      Here is a patch which uses the same technique as CUR_NONE for hiding the
      cursor while still moving it.
      Mario, you should apply it to the speakup kernel for access floppies
      asap. I'll submit a 2.4 patch too.
      Signed-off-by: samuel.thibault@ens-lyon.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  29. 31 Oct, 2005 1 commit
    • Pozsar Balazs's avatar
      [PATCH] fix vgacon blanking · 1a66ddcb
      Pozsar Balazs authored
      This patch fixes a long-standing vgacon bug: characters with the bright bit
      set were left on the screen and not blacked out.  All I did was that I
      lookuped up some examples on the net about setting the vga palette, and
      added the call missing from the linux kernel, but included in all other
      ones.  It works for me.
      You can test this by writing something with the bright set to the
      console, for example:
        echo -e "\e[1;31mhello there\e[0m"
      and then wait for the console to blank itself (by default, after 10 mins
      of inactivity), maybe making it faster using
        setterm -blank 1
      so you only have to wait 1 minute.
      Signed-off-by: default avatarPozsar Balazs <pozsy@uhulinux.hu>
      Cc: James Simmons <jsimmons@infradead.org>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  30. 17 Oct, 2005 1 commit
    • Samuel Thibault's avatar
      [PATCH] SVGATextMode fix · 0aec4867
      Samuel Thibault authored
      Fix bug 5441.
      I didn't know about messy programs like svgatextmode...  Couldn't this be
      integrated in some linux/drivers/video/console/svgacon.c ?...  So because
      of the existence of the svgatextmode program, the kernel is not supposed to
      Disabling the check in vgacon_resize() might help indeed, but I'm really
      not sure whether it will work for any chipset: in my patch, CRT registers
      are set at each console switch, since stty rows/cols apply to consoles
      The attached solution is to keep the test, but if it fails, we assume that
      the caller knows what it does (i.e.  it is svgatextmode) and then disable
      any further call to vgacon_doresize.  Svgatextmode is usually used to
      _expand_ the display, not to shrink it.  And it is harmless in the case of
      a too big stty rows/cols: the display will just be cropped.  I tested it on
      my laptop, and it works fine with svgatextmode.
      A better solution would be that svgatextmode explicitely tells the kernel
      not to care about video timing, but for this an interface needs be defined
      and svgatextmode be patched.
      Signed-off-by: default avatarSamuel Thibault <samuel.thibault@ens-lyon.org>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  31. 15 Sep, 2005 1 commit
    • Antonino A. Daplas's avatar
      [PATCH] vgacon: Fix sanity checking in vgacon_resize · 6d36ba62
      Antonino A. Daplas authored
      Reported by: walt <wa1ter@myrealbox.com>
      "I routinely switch the console font during bootup to
      8x8 so I can get 50 lines per screen.  Until 09 Sept,
      just changing to the small font automatically gave me
      all 50 lines -- but now I'm only getting 25 lines even
      with the small font.  The bottom half of the screen
      displays the text that already scrolled off the top."
      This bug is due to an erroneous check in the recently added hook,
      vgacon_resize(). It checks the new height against the original number of
      rows of the console. Because the original number of rows depends on both
      the scanline and the font height, check it instead against the
      Signed-off-by: default avatarAntonino Daplas <adaplas@pol.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  32. 09 Sep, 2005 1 commit
  33. 22 Jun, 2005 1 commit
    • James Simmons's avatar
      [PATCH] VGA to fbcon fix. · f18cd8f7
      James Simmons authored
      Currently when going from vgacon to fbcon the VT screenbuffer are often
      different sizes.  In the case when they are different sizes a new VT
      screenbuffer is allocated and the contents are copied into the new buffer.
      Currently the amount copied from VGA text memory to the new screenbuf is
      the size of the framebuffer console.  If the framebuffer console new VT
      screen buffer is greater than the VGA text memory size then we get some of
      the VGA BIOS contents as well.
      This patch will only allow you to copy up to the size of VGA text memory
      now.  The rest is filled with erase characters.
      Initial patch by Jordan Crouse <jordan.crouse@amd.com>
      Signed-off-by: default avatarJames Simmons <jsimmons@www.infradead.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>