Commit Graph

8 Commits

Author SHA1 Message Date
Tobias Klauser d1ae418eef [PATCH] drivers/video: Use ARRAY_SIZE macro
Use ARRAY_SIZE macro instead of sizeof(x)/sizeof(x[0]) and remove
duplicates of ARRAY_SIZE.  Some coding style and trailing whitespaces are
also fixed.

Compile-tested where possible (some are other arch or BROKEN)

Signed-off-by: Tobias Klauser <tklauser@nuerscht.ch>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-27 08:44:58 -08:00
Antonino A. Daplas 6af7ffc414 [PATCH] neofb: Fix uninitialized value
Remove insignificant and unitialized variable "waitcycles" from neo2200_sync.

Coverity Bug 895

Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-11 09:19:35 -08:00
Christian Trefzer 9f672004ab [PATCH] neofb: avoid resetting display config on unblank (v2)
There were two mistakes in the register-read-on-(un)blank approach.

- First, without proper register (un)locking the value read back will always
  be zero, and this is what I missed entirely until just now.  Due to this,
  the logic could not be verified at all and I tried some bogus checks which
  are completely stupid.

- Second, the LCD status bit will always be set to zero when the backlight
  has been turned off.  Reading the value back during unblank will disable the
  LCD unconditionally, regardless of the state it is supposed to be in, since
  we set it to zero beforehand.

So this is what we do now:

- create a new variable in struct neofb_par, and use that to determine
  whether to read back registers (initialized to true)

- before actually blanking the screen, read back the register to sense any
  possible change made through Fn key combo

- use proper neoUnlock() / neoLock() to actually read something

- every call to neofb_blank() determines if we read back next time: blanking
  disables readback, unblanking (FB_BLANK_UNBLANK) enables it

This should give us a nice and clean state machine.  Has been thoroughly
tested on a Dell Latitude CPiA / NM220 Chip docked to a C/Dock2 with attached
CRT in all possible combinations of LCD/CRT on/off.  I changed the config via
Fn key, let the console blank, unblanked by keypress - works flawlessly.

Signed-off-by: Christian Trefzer <ctrefzer@gmx.de>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-15 15:32:21 -08:00
Christian Trefzer 10ee39fe3f [PATCH] neofb: avoid resetting display config on unblank
Fix issues with the NeoMagic framebuffer driver.

It nicely complements my previous fix already in linus' tree.  The only
thing missing now is that the external CRT will not be activated at neofb
init when external-only is selected, either by register read or
module/kernel parameter.

Testing was done on a Dell Latitude CPi-A/NM2200 chip.

Previous behaviour:
- before booting linux, set the preferred display config X via FN+F8

- boot linux, neofb stores the register values in a private
  variable

- change the display config to Y via keystroke

- leave the machine in peace until display is blanked

- touching any key will result in display config X being restored

- booting up, the BIOS will acknowledge config Y, though...

Current behaviour:
At the time of unblanking, config Y is honoured because we now read back
register contents instead of just overwriting them with outdated values.

Signed-off by: Christian Trefzer <ctrefzer@gmx.de>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-14 16:09:35 -08:00
Christian Trefzer 4836f5749e [PATCH] neofb: take existing display configuration as default
On a Dell Latitude CPi-A I noticed a strangeness wrt.  the handling of an
external monitor by the neomagic framebuffer driver, namely when the laptop is
docked in a C/Dock II with the lid shut.

A cold boot would result in the BIOS configuring the video chip to use the
"external monitor only" mode, yet neofb would default to "internal LCD only".
An attempt for a quick fix by using the Fn-F8 keystroke to toggle the display
combination modes resulted in a reproductible hard lock, powering down being
the only solution.

The attached patch makes neofb probe the register for the current display
mode, using that value as a default if nothing was specified as kernel/module
parameter.

Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-14 18:27:14 -08:00
Antonino A. Daplas 9f19bc56c3 [PATCH] fbdev: neofb: Driver cleanups
- remove unneeded casts
- move memory for pseudo_palette inside struct neofb_par

Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-10 08:01:45 -08:00
Antonino A. Daplas c465e05a03 [PATCH] fbcon/fbdev: Move softcursor out of fbdev to fbcon
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 <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-07 07:53:50 -08:00
Linus Torvalds 1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00