1. 29 5月, 2014 1 次提交
    • T
      vgacon: Fix & cleanup refcounting · 0f2893f0
      Takashi Iwai 提交于
      The vgacon driver prepares a two element array of uni_pagedir_loc and
      uses the second item as its own reference counter for sharing the
      uni_pagedir.  And the code assumes blindly that the second item is
      available if the assigned vc_uni_pagedir isn't the standard one, which
      might be wrong (although currently it's so).
      
      This patch fixes that wrong assumption, and gives a slight cleanup
      along with it: namely, instead of array, just give the uni_pagedir_loc
      and a separate refcount variable.  It makes the code a bit more
      understandable at first glance.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0f2893f0
  2. 27 6月, 2013 1 次提交
  3. 26 6月, 2013 1 次提交
  4. 07 2月, 2013 1 次提交
    • D
      vgacon/vt: clear buffer attributes when we load a 512 character font (v2) · 2a248307
      Dave Airlie 提交于
      When we switch from 256->512 byte font rendering mode, it means the
      current contents of the screen is being reinterpreted. The bit that holds
      the high bit of the 9-bit font, may have been previously set, and thus
      the new font misrenders.
      
      The problem case we see is grub2 writes spaces with the bit set, so it
      ends up with data like 0x820, which gets reinterpreted into 0x120 char
      which the font translates into G with a circumflex. This flashes up on
      screen at boot and is quite ugly.
      
      A current side effect of this patch though is that any rendering on the
      screen changes color to a slightly darker color, but at least the screen
      no longer corrupts.
      
      v2: as suggested by hpa, always clear the attribute space, whether we
      are are going to or from 512 chars.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      2a248307
  5. 13 9月, 2011 1 次提交
  6. 25 1月, 2011 1 次提交
  7. 14 1月, 2011 1 次提交
    • Y
      vgacon: check for efi machine · 554ec37a
      Yannick Heneault 提交于
      It seems there is a small problem of VGA palette corruption on EFI
      machine.  When the kernel initializes the architecture, it checks if the
      machine is a EFI machine and assumes that a VGA console can exist.
      
      When it initializes the console in vgacon_startup it checks if it can
      really use the VGA console.  I think this is where a check is missing.
      Currently, the function can fail if a VESA boot mode is detected but not if
      a EFI boot mode was used.
      
      Thus vgacon_startup() doesn't fail and initialize the video card for a real
      VGA mode.  This function changes the first 16entries of the VGA palette.
      
      When the efifb driver kicks in, the palette is not restored to default
      ramp value, thus the 16 first entry remain in a modified state.  The
      following patch prevent this corruption.
      Signed-off-by: NYannick Heneault <yheneaul@matrox.com>
      Cc: Dave Airlie <airlied@linux.ie>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      554ec37a
  8. 18 11月, 2010 1 次提交
  9. 11 8月, 2010 2 次提交
  10. 07 3月, 2010 1 次提交
  11. 14 11月, 2009 2 次提交
  12. 23 9月, 2009 1 次提交
  13. 20 9月, 2009 1 次提交
  14. 12 6月, 2009 1 次提交
  15. 03 5月, 2009 1 次提交
  16. 06 1月, 2009 1 次提交
  17. 29 12月, 2008 1 次提交
    • D
      DRM: add mode setting support · f453ba04
      Dave Airlie 提交于
      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
          configurations
        - 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: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      f453ba04
  18. 17 10月, 2008 2 次提交
  19. 15 10月, 2008 1 次提交
  20. 29 4月, 2008 1 次提交
    • J
      vt: fix background color on line feed · c9e587ab
      Jan Engelhardt 提交于
      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"'
      and
      	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
      color.
      
      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: NJan 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c9e587ab
  21. 07 2月, 2008 1 次提交
  22. 17 10月, 2007 3 次提交
  23. 22 7月, 2007 1 次提交
  24. 17 5月, 2007 1 次提交
  25. 09 5月, 2007 3 次提交
  26. 03 5月, 2007 1 次提交
  27. 15 2月, 2007 1 次提交
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      Tim Schmielau 提交于
      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: NTim Schmielau <tim@physik3.uni-rostock.de>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a
  28. 09 12月, 2006 1 次提交
  29. 11 7月, 2006 2 次提交
  30. 01 7月, 2006 1 次提交
  31. 28 6月, 2006 1 次提交
  32. 27 6月, 2006 1 次提交
    • A
      [PATCH] Detaching fbcon: fix vgacon to allow retaking of the console · 50ec42ed
      Antonino A. Daplas 提交于
      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
      reboot.
      
      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
        take_over_console().
      
      - 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: NAntonino Daplas <adaplas@pol.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      50ec42ed