1. 23 9月, 2010 1 次提交
    • J
      fbcon: fix lockdep warning from fbcon_deinit() · 142092e5
      Jarek Poplawski 提交于
      Fix the lockdep warning:
      
      [   13.657164] INFO: trying to register non-static key.
      [   13.657169] the code is fine but needs lockdep annotation.
      [   13.657171] turning off the locking correctness validator.
      [   13.657177] Pid: 622, comm: modprobe Not tainted 2.6.36-rc3c #8
      [   13.657180] Call Trace:
      [   13.657194]  [<c13002c8>] ? printk+0x18/0x20
      [   13.657202]  [<c1056cf6>] register_lock_class+0x336/0x350
      [   13.657208]  [<c1058bf9>] __lock_acquire+0x449/0x1180
      [   13.657215]  [<c1059997>] lock_acquire+0x67/0x80
      [   13.657222]  [<c1042bf1>] ? __cancel_work_timer+0x51/0x230
      [   13.657227]  [<c1042c23>] __cancel_work_timer+0x83/0x230
      [   13.657231]  [<c1042bf1>] ? __cancel_work_timer+0x51/0x230
      [   13.657236]  [<c10582b2>] ? mark_held_locks+0x62/0x80
      [   13.657243]  [<c10b3a2f>] ? kfree+0x7f/0xe0
      [   13.657248]  [<c105853c>] ? trace_hardirqs_on_caller+0x11c/0x160
      [   13.657253]  [<c105858b>] ? trace_hardirqs_on+0xb/0x10
      [   13.657259]  [<c117f4cd>] ? fbcon_deinit+0x16d/0x1e0
      [   13.657263]  [<c117f4cd>] ? fbcon_deinit+0x16d/0x1e0
      [   13.657268]  [<c1042dea>] cancel_work_sync+0xa/0x10
      [   13.657272]  [<c117f444>] fbcon_deinit+0xe4/0x1e0
      ...
      
      The warning is caused by trying to cancel an uninitialized work from
      fbcon_exit().  Fix it by adding a check for queue.func, similarly to other
      places in this code.
      Signed-off-by: NJarek Poplawski <jarkao2@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      142092e5
  2. 11 8月, 2010 2 次提交
  3. 05 8月, 2010 1 次提交
  4. 01 3月, 2010 1 次提交
    • D
      vga_switcheroo: initial implementation (v15) · 6a9ee8af
      Dave Airlie 提交于
      Many new laptops now come with 2 gpus, one to be used for low power
      modes and one for gaming/on-ac applications. These GPUs are typically
      wired to the laptop panel and VGA ports via a multiplexer unit which
      is controlled via ACPI methods.
      
      4 combinations of systems typically exist - with 2 ACPI methods.
      Intel/ATI - Lenovo W500/T500 - use ATPX ACPI method
      ATI/ATI - some ASUS - use ATPX ACPI Method
      Intel/Nvidia - - use _DSM ACPI method
      Nvidia/Nvidia -  - use _DSM ACPI method.
      
      TODO:
      This patch adds support for the ATPX method and initial bits
      for the _DSM methods that need to written by someone with
      access to the hardware.
      Add a proper non-debugfs interface - need to get some proper
      testing first.
      
      v2: add power up/down support for both devices
      on W500 puts i915/radeon into D3 and cuts power to radeon.
      
      v3: redo probing methods, no DMI list, drm devices call to
      register with switcheroo, it tries to find an ATPX method on
      any device and once there is two devices + ATPX it inits the
      switcher.
      
      v4: ATPX msg handling using buffers - should work on more machines
      
      v5: rearchitect after more mjg59 discussion - move ATPX handling to
          radeon driver.
      
      v6: add file headers + initial nouveau bits (to be filled out).
      
      v7: merge delayed switcher code.
      
      v8: avoid suspend/resume of gpu that is off
      
      v9: rearchitect - mjg59 is always right. - move all ATPX code to
      radeon, should allow simpler DSM also proper ATRM handling
      
      v10: add ATRM support for radeon BIOS, add mutex to lock vgasr_priv
      
      v11: fix bug in resuming Intel for 2nd time.
      
      v12: start fixing up nvidia code blindly.
      
      v13: blindly guess at finishing nvidia code
      
      v14: remove radeon audio hacks - fix up intel resume more like upstream
      
      v15: clean up printks + remove unnecessary igd/dis pointers
      
      mount debugfs
      
      /sys/kernel/debug/vgaswitcheroo/switch - should exist if ATPX detected
       + 2 cards.
      
      DIS - immediate change to discrete
      IGD - immediate change to IGD
      DDIS - delayed change to discrete
      DIGD - delayed change to IGD
      ON - turn on not in use
      OFF - turn off not in use
      
      Tested on W500 (Intel/ATI) and T500 (Intel/ATI)
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      6a9ee8af
  5. 12 11月, 2009 1 次提交
  6. 23 9月, 2009 2 次提交
    • I
      fbcon: only unbind from console if successfully registered · 2ddce3fd
      Ian Armstrong 提交于
      Attempting to unload a framebuffer module calls unregister_framebuffer()
      which in turn gets fbcon to release it.  If fbcon has no framebuffers
      linked to a console, it will also unbind itself from the console driver.
      However, if fbcon never registered itself as a console driver, the unbind
      will fail causing the framebuffer device entry to persist.  In most cases
      this failure will result in an oops when attempting to access the now
      non-existent device.
      
      This patch ensures that the fbcon unbind request will succeed even if a
      bind was never done.  It tracks if a successful bind ever occurred & will
      only attempt to unbind if needed.  If there never was a bind, it simply
      returns with no error.
      Signed-off-by: NIan Armstrong <ian@iarmst.demon.co.uk>
      Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2ddce3fd
    • F
      fb: do not ignore fb_set_par errors · 0fcf6ada
      Florian Tobias Schandinat 提交于
      At the moment about half of the framebuffer drivers can return an error
      code in fb_set_par. Until now it would be silently ignored by fbmem.c
      and fbcon.c. This patch fixes fbmem.c to return the error code and
      restore var on error.
      
      But it is not clear in which video mode the device is when fb_set_par
      fails.  It would be good and reasonable if it were in the old state but
      there is no guarantee that this is true for all existing drivers.
      Additionally print a message if a failing fb_set_par is detected in
      fbmem.c or fbcon.c.
      
      Although most errors should be caught by the previous fb_check_var some
      errors can't as they are dynamic (memory allocations, ...) and can only be
      detected while performing the operations which is forbidden in
      fb_check_var.
      
      This patch shouldn't have a negative impact on normal operation as all
      drivers return 0 on success.  The impact in case of error depends heavily
      on the driver and caller but it's expected to be better than before.
      Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0fcf6ada
  7. 08 8月, 2009 1 次提交
    • J
      fbcon: don't use vc_resize() on initialization · 0035fe00
      Johannes Weiner 提交于
      Catalin and kmemleak spotted a leak of a VC screen buffer in
      vc_allocate() due to the following chain of events:
      
      	vc_allocate()
      	  visual_init(init=1)
      	    vc->vc_sw->con_init(init=1)
                    fbcon_init()
      	        vc_resize()
      	          vc->screen_buf = kmalloc()
      	  vc->screen_buf = kmalloc()
      
      The common way for the VC drivers is to set the screen dimension
      parameters manually in the init case and only call vc_resize() for
      !init - which allocates a screen buffer according to the new
      dimensions.
      
      fbcon instead would do vc_resize() unconditionally and afterwards set
      the dimensions manually (again) for !init - i.e. completely upside
      down.  The vc_resize() allocated buffer would then get lost by
      vc_allocate() allocating a fresh one.
      
      Use vc_resize() only for actual resizing to close the leak.
      
      Set the dimensions manually only in initialization mode to remove the
      redundant setting in resize mode.
      
      The kmemleak trace from Catalin:
      
      unreferenced object 0xde158000 (size 12288):
        comm "Xorg", pid 1439, jiffies 4294961016
        hex dump (first 32 bytes):
          20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00   . . . . . . . .
          20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00   . . . . . . . .
        backtrace:
          [<c006f74b>] __save_stack_trace+0x17/0x1c
          [<c006f81d>] create_object+0xcd/0x188
          [<c01f5457>] kmemleak_alloc+0x1b/0x3c
          [<c006e303>] __kmalloc+0xdb/0xe8
          [<c012cc4b>] vc_do_resize+0x73/0x1e0
          [<c012cdf1>] vc_resize+0x15/0x18
          [<c011afc1>] fbcon_init+0x1f9/0x2b8
          [<c0129e87>] visual_init+0x9f/0xdc
          [<c012aff3>] vc_allocate+0x7f/0xfc
          [<c012b087>] con_open+0x17/0x80
          [<c0120e43>] tty_open+0x1f7/0x2e4
          [<c0072fa1>] chrdev_open+0x101/0x118
          [<c006ffad>] __dentry_open+0x105/0x1cc
          [<c00700fd>] nameidata_to_filp+0x2d/0x38
          [<c00788cd>] do_filp_open+0x2c1/0x54c
          [<c006fdff>] do_sys_open+0x3b/0xb4
      Reported-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NJohannes Weiner <hannes@cmpxchg.org>
      Tested-by: NCatalin Marinas <catalin.marinas@arm.com>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
      Tested-by: NDave Young <hidave.darkstar@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0035fe00
  8. 14 4月, 2009 1 次提交
  9. 01 4月, 2009 1 次提交
  10. 13 1月, 2009 1 次提交
  11. 29 12月, 2008 2 次提交
  12. 11 12月, 2008 1 次提交
    • G
      fbcon: fix workqueue shutdown · beaa4867
      Geoff Levand 提交于
      Add a call to cancel_work_sync() in fbcon_exit() to cancel any pending
      work in the fbcon workqueue.
      
      The current implementation of fbcon_exit() sets the fbcon workqueue
      function info->queue.func to NULL, but does not assure that there is no
      work pending when it does so.  On occasion, depending on system timing,
      there will still be pending work in the queue when fbcon_exit() is
      called.  This results in a null pointer deference when run_workqueue()
      tries to call the queue's work function.
      
      Fixes errors on shutdown similar to these:
      
        Console: switching to colour dummy device 80x25
        Unable to handle kernel paging request for data at address 0x00000000
      Signed-off-by: NGeoff Levand <geoffrey.levand@am.sony.com>
      Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      beaa4867
  13. 02 12月, 2008 1 次提交
    • D
      fbdev: fix FB console blanking · bca404af
      Dmitry Baryshkov 提交于
      The commit aef7db4b fixed the problem with
      recursive locking in fb blanking code if blank is caused by user setting
      the /sys/class/graphics/fb*/blank.  However this broke the fbcon timeout
      blanking.
      
      If you use a driver that defines ->fb_blank operation and at the same time
      that driver relies on other driver (e.g.  backlight or lcd class) to blank
      the screen, when the fbcon times out and tries to blank the fb, it will
      call only fb driver blanker and won't notify the other driver.  Thus FB
      output is disabled, but the screen isn't blanked.
      
      Restore fbcon blanking and at the same time apply the proper fix for the
      above problem: if fbcon_blank is called with FBINFO_FLAG_USEREVENT, we are
      already called through notification from fb_blank, thus we don't have to
      blank the fb again.
      Signed-off-by: NDmitry Baryshkov <dbaryshkov@gmail.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bca404af
  14. 31 10月, 2008 1 次提交
  15. 17 10月, 2008 2 次提交
    • O
      fbcon_set_all_vcs: fix kernel crash when switching the rotated consoles · 232fb69a
      Oleg Nesterov 提交于
      echo 3 >> /sys/class/graphics/fbcon/rotate_all, then switch to another
      console. Result:
      
      	BUG: unable to handle kernel paging request at ffffc20005d00000
      	IP: [bitfill_aligned+149/265] bitfill_aligned+0x95/0x109
      	PGD 7e228067 PUD 7e229067 PMD 7bc1f067 PTE 0
      	Oops: 0002 [1] SMP
      	CPU 1
      	Modules linked in: [...a lot...]
      	Pid: 10, comm: events/1 Not tainted 2.6.26.5-45.fc9.x86_64 #1
      	RIP: 0010:[bitfill_aligned+149/265]  [bitfill_aligned+149/265] bitfill_aligned+0x95/0x109
      	RSP: 0018:ffff81007d811bc8  EFLAGS: 00010216
      	RAX: ffffc20005d00000 RBX: 0000000000000000 RCX: 0000000000000400
      	RDX: 0000000000000000 RSI: ffffc20005d00000 RDI: ffffffffffffffff
      	RBP: ffff81007d811be0 R08: 0000000000000400 R09: 0000000000000040
      	R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000010000
      	R13: ffffffff811632f0 R14: 0000000000000006 R15: ffff81007cb85400
      	FS:  0000000000000000(0000) GS:ffff81007e004780(0000) knlGS:0000000000000000
      	CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
      	CR2: ffffc20005d00000 CR3: 0000000000201000 CR4: 00000000000006e0
      	DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      	DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      	Process events/1 (pid: 10, threadinfo ffff81007d810000, task ffff81007d808000)
      	Stack:  ffff81007c9d75a0 0000000000000000 0000000000000000 ffff81007d811c80
      	 ffffffff81163a61 ffff810000000000 ffffffff8115f9c8 0000001000000000
      	 0000000100aaaaaa 000000007cd0d4a0 fffffd8a00000800 0001000000000000
      	Call Trace:
      	 [cfb_fillrect+523/798] cfb_fillrect+0x20b/0x31e
      	 [soft_cursor+416/436] ? soft_cursor+0x1a0/0x1b4
      	 [ccw_clear_margins+205/263] ccw_clear_margins+0xcd/0x107
      	 [fbcon_clear_margins+59/61] fbcon_clear_margins+0x3b/0x3d
      	 [fbcon_switch+1291/1466] fbcon_switch+0x50b/0x5ba
      	 [redraw_screen+261/481] redraw_screen+0x105/0x1e1
      	 [ccw_cursor+0/1869] ? ccw_cursor+0x0/0x74d
      	 [complete_change_console+48/190] complete_change_console+0x30/0xbe
      	 [change_console+115/120] change_console+0x73/0x78
      	 [console_callback+0/292] ? console_callback+0x0/0x124
      	 [console_callback+97/292] console_callback+0x61/0x124
      	 [schedule_delayed_work+25/30] ? schedule_delayed_work+0x19/0x1e
      	 [run_workqueue+139/282] run_workqueue+0x8b/0x11a
      	 [worker_thread+221/238] worker_thread+0xdd/0xee
      	 [autoremove_wake_function+0/56] ? autoremove_wake_function+0x0/0x38
      	 [worker_thread+0/238] ? worker_thread+0x0/0xee
      	 [kthread+73/118] kthread+0x49/0x76
      	 [child_rip+10/18] child_rip+0xa/0x12
      	 [kthread+0/118] ? kthread+0x0/0x76
      	 [child_rip+0/18] ? child_rip+0x0/0x12
      
      Because fbcon_set_all_vcs()->FBCON_SWAP() uses display->rotate == 0 instead
      of fbcon_ops->rotate, and vc_resize() has no effect because it is called with
      new_cols/rows == ->vc_cols/rows.
      
      Tested on 2.6.26.5-45.fc9.x86_64, but
      http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git seems to
      have the same problem.
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
      Cc: <stable@kernel.org>	[2.6.27.x, 2.6.26.x, maybe 2.6.25.x]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      232fb69a
    • G
      device create: video: convert device_create_drvdata to device_create · 77997aaa
      Greg Kroah-Hartman 提交于
      Now that device_create() has been audited, rename things back to the
      original call to be sane.
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      77997aaa
  16. 15 10月, 2008 1 次提交
  17. 04 10月, 2008 1 次提交
    • K
      fbdev: fix recursive notifier and locking when fbdev console is blanked · aef7db4b
      Krzysztof Helt 提交于
      Fix infinite recursive notifier in the fbdev layer.  This causes recursive
      locking.  Dmitry Baryshkov found the problem and confirmed that the patch
      fixes the bug.
      
      After doing
      # echo 1 > /sys/class/graphics/fb0/blank
      I got the following in my kernel log:
      
      =============================================
      [ INFO: possible recursive locking detected ]
      2.6.27-rc6-00086-gda63874-dirty #97
      ---------------------------------------------
      echo/1564 is trying to acquire lock:
       ((fb_notifier_list).rwsem){..--}, at: [<c005a384>] __blocking_notifier_call_chain+0x38/0x6c
      
      but task is already holding lock:
       ((fb_notifier_list).rwsem){..--}, at: [<c005a384>] __blocking_notifier_call_chain+0x38/0x6c
      
      other info that might help us debug this:
      2 locks held by echo/1564:
       #0:  (&buffer->mutex){--..}, at: [<c00ddde0>] sysfs_write_file+0x30/0x80
       #1:  ((fb_notifier_list).rwsem){..--}, at: [<c005a384>] __blocking_notifier_call_chain+0x38/0x6c
      
      stack backtrace:
      [<c0029fe4>] (dump_stack+0x0/0x14) from [<c0060ce0>] (print_deadlock_bug+0xa4/0xd0)
      [<c0060c3c>] (print_deadlock_bug+0x0/0xd0) from [<c0060e54>] (check_deadlock+0x148/0x17c)
       r6:c397a1e0 r5:c397a530 r4:c04fcf98
      [<c0060d0c>] (check_deadlock+0x0/0x17c) from [<c00637e8>] (validate_chain+0x3c4/0x4f0)
      [<c0063424>] (validate_chain+0x0/0x4f0) from [<c0063efc>] (__lock_acquire+0x5e8/0x6b4)
      [<c0063914>] (__lock_acquire+0x0/0x6b4) from [<c006402c>] (lock_acquire+0x64/0x78)
      [<c0063fc8>] (lock_acquire+0x0/0x78) from [<c0316ca8>] (down_read+0x4c/0x60)
       r7:00000009 r6:ffffffff r5:c0427a40 r4:c005a384
      [<c0316c5c>] (down_read+0x0/0x60) from [<c005a384>] (__blocking_notifier_call_chain+0x38/0x6c)
       r5:c0427a40 r4:c0427a74
      [<c005a34c>] (__blocking_notifier_call_chain+0x0/0x6c) from [<c005a3d8>] (blocking_notifier_call_chain+0x20/0x28)
       r8:00000009 r7:c086d640 r6:c3967940 r5:00000000 r4:c38984b8
      [<c005a3b8>] (blocking_notifier_call_chain+0x0/0x28) from [<c014baa0>] (fb_notifier_call_chain+0x1c/0x24)
      [<c014ba84>] (fb_notifier_call_chain+0x0/0x24) from [<c014c18c>] (fb_blank+0x64/0x70)
      [<c014c128>] (fb_blank+0x0/0x70) from [<c0155978>] (fbcon_blank+0x114/0x1bc)
       r5:00000001 r4:c38984b8
      [<c0155864>] (fbcon_blank+0x0/0x1bc) from [<c0170ea8>] (do_blank_screen+0x1e0/0x2a0)
      [<c0170cc8>] (do_blank_screen+0x0/0x2a0) from [<c0154024>] (fbcon_fb_blanked+0x74/0x94)
       r5:c3967940 r4:00000001
      [<c0153fb0>] (fbcon_fb_blanked+0x0/0x94) from [<c0154228>] (fbcon_event_notify+0x100/0x12c)
       r5:fffffffe r4:c39bc194
      [<c0154128>] (fbcon_event_notify+0x0/0x12c) from [<c005a0d4>] (notifier_call_chain+0x38/0x7c)
      [<c005a09c>] (notifier_call_chain+0x0/0x7c) from [<c005a3a0>] (__blocking_notifier_call_chain+0x54/0x6c)
       r8:c3b51ea0 r7:00000009 r6:ffffffff r5:c0427a40 r4:c0427a74
      [<c005a34c>] (__blocking_notifier_call_chain+0x0/0x6c) from [<c005a3d8>] (blocking_notifier_call_chain+0x20/0x28)
       r8:00000001 r7:c3a7e000 r6:00000000 r5:00000000 r4:c38984b8
      [<c005a3b8>] (blocking_notifier_call_chain+0x0/0x28) from [<c014baa0>] (fb_notifier_call_chain+0x1c/0x24)
      [<c014ba84>] (fb_notifier_call_chain+0x0/0x24) from [<c014c18c>] (fb_blank+0x64/0x70)
      [<c014c128>] (fb_blank+0x0/0x70) from [<c014e450>] (store_blank+0x54/0x7c)
       r5:c38984b8 r4:c3b51ec4
      [<c014e3fc>] (store_blank+0x0/0x7c) from [<c017981c>] (dev_attr_store+0x28/0x2c)
       r8:00000001 r7:c042bf80 r6:c39eba10 r5:c3967c30 r4:c38e0140
      [<c01797f4>] (dev_attr_store+0x0/0x2c) from [<c00ddaac>] (flush_write_buffer+0x54/0x68)
      [<c00dda58>] (flush_write_buffer+0x0/0x68) from [<c00dde08>] (sysfs_write_file+0x58/0x80)
       r8:c3b51f78 r7:c3bcb070 r6:c39eba10 r5:00000001 r4:00000001
      [<c00dddb0>] (sysfs_write_file+0x0/0x80) from [<c009de04>] (vfs_write+0xb8/0x148)
      [<c009dd4c>] (vfs_write+0x0/0x148) from [<c009e384>] (sys_write+0x44/0x70)
       r7:00000004 r6:c3bcb070 r5:00000000 r4:00000000
      [<c009e340>] (sys_write+0x0/0x70) from [<c0025d00>] (ret_fast_syscall+0x0/0x2c)
       r6:4001b000 r5:00000001 r4:401dc658
      Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
      Reported-by: NDmitry Baryshkov <dbaryshkov@gmail.com>
      Testted-by: NDmitry Baryshkov <dbaryshkov@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      aef7db4b
  18. 13 8月, 2008 1 次提交
  19. 06 8月, 2008 1 次提交
  20. 25 7月, 2008 1 次提交
  21. 22 7月, 2008 1 次提交
  22. 07 6月, 2008 1 次提交
  23. 13 5月, 2008 2 次提交
  24. 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
  25. 28 4月, 2008 2 次提交
  26. 07 2月, 2008 4 次提交
  27. 17 10月, 2007 3 次提交
  28. 12 8月, 2007 1 次提交
  29. 18 7月, 2007 1 次提交
    • J
      fbdev: fbcon: console unregistration from unregister_framebuffer · cfafca80
      Jesse Barnes 提交于
      This allows for proper console unregistration via the VT layer, and updates
      the FB layer to use it.  This makes debugging new console drivers much easier,
      since you can properly clean them up before unloading.
      
      [adaplas]
      unregister_framebuffer() is typically called as part of the driver's
      module_exit(). Doing so otherwise will freeze the machine as the VT layer is
      holding reference counts on fbcon, and fbcon on the driver.  With this change,
      it allows unregister_framebuffer() to be called safely anywhere as needed.
      
      Additions from the original:  If multiple drivers are used by fbcon, and if
      one of them unregisters, a driver will take over the consoles vacated by the
      outgoing one (via set_con2fb_map).   Once only the outgoing driver remains,
      then fbcon will unbind from the VT layer (if CONFIG_HW_CONSOLE_UNBINDING is
      set to y).
      
      It is important that these drivers implement fb_open() and fb_release()
      just to ensure that no other process is using the driver. Likewise, these
      drivers _must_ check the return value of unregister_framebuffer().
      
      [akpm@linux-foundation.org: make fbcon_unbind() stub inline]
      Signed-off-by: NJesse Barnes <jesse.barnes@intel.com>
      Signed-off-by: NAntonino Daplas <adaplas@gmail.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cfafca80