Bug 156583

Sorry, I don't understand this bugreport. What 'rectangle' and what icon?

the laptop has a button in the middle of the two mouse buttons under the touchpad (see here: http://udoburghardt.de/udo/laptop2/images/x20.jpg)

pressing that one enables/disables the touchpad. when running under windows xp, I see an icon OSD overlay in the upper left corner that gives user feedback (an icon with text "enabled touchpad" etc). 

under linux, this works too, but there is no icon/text, just a black rectangle for two seconds. 

http://udoburghardt.de/udo/laptop2/index.shtml#probleme lists it (sorry, german): 

Visuelle Rückmeldung: Einige Funktionen, die durch Sondertasten ausgelöst werden können, besitzen eine visuelle Rückmeldung. Die links oben in der Bildschirmecke eingeblendeten Piktogramme sind bei mir im Normalfall vollständig defekt und werden nur als Pixelmüll angezeigt. Interessanterweise funktioniert das nach einem Suspend/Restore-Zyklus absolut korrekt!
Lösung: vbetool Jens Lautenbacher hat mich auf vbetool hingewiesen. Mit einem (am Anfang von /etc/init.d/xfree86-common, an die gleiche Stelle wie den oben erwähnten 855resolution-Aufruf) eingefügten vbetool post erledigt sich das Problem. Ich kannte auch dieses Progrämmchen noch nicht, die man-page sagt:
DESCRIPTION
vbetool uses lrmi in  order to run code from the video BIOS.
Currently, it is able to alter DPMS states, save/restore video card 
state and attempt to initialize the video card from scratch.
 Nun geht die Piktogrammanzeige sofort, versagt aber erneut nach einem Suspend2Disk! Also habe ich den Aufruf auch noch ins /etc/acpi/sleepbtn.sh-script eingetragen, was dann wiederum zu einem schwarzen Bildschirm und einem zwangsweise manuellem Ctrl-Alt-F1 - Alt-F7-Zyklus führt. Ich habs also hier wieder ausgetragen, Suspend verwende ich sowieso nicht häufig...

Ok, so this looks like something we can fix at least with a workaround.

Sebastian, does the X05 you have from us show the same problem? Black or destroyed icon when 'special keys' are pressed? I know there was a problem once, but I thought that was fixed.
If it's a general Samsung problem we should take that into account :)

The x05 does not have such a button, but I'm able to reproduce it w/ the battery status function key (Fn-F2 on the x05). This gives you a scrambled rectangle in the upper left display corner (NLD10-beta7). So it seems to be true for any osd overlay, and it's not only related to X.
But the behavior over all is very strange, because if you use the osd during bootup, the issue won't show up, not even in X.

HW: Samsung x-Series laptops with intel graphics (855GM)

Issue: intel_agp blocks osd overlays from updating/writing their contents.

How-to-reproduce: The black/scrambled rectangle isn't a good indicator for this issue, because it's broken, even if the content seems to be displayed accurately.
Test with any function key that display its status on-screen:
E.g. LCD-brightness, battery status. Even if it seems that the osd works correctly, it's not able to update its contents. E.g. if you first use battery status, and afterwards adjust the brightness, the osd will still show the contents of battery status.

Issues/Workarounds:
I found 3 issues related to this:
1. intel_agp/agpgart does the bad thing, because it doesn't matter wheather you
   use i915 or intelfb - as soon as /dev/agpgart is accessable, osd will be
   broken.
   => Note if we are not able to fix intel_agp/agpgart blacklisting intel_agp
      works around all 3 issues (but disables accel gfx).
2. "modprobe i915" or "modprobe intelfb" does not pull intel_agp. This could
   be the reason why some might think the issue is gone sometimes.
   This means, if you modprobe i915, you do not really use accel driver, because
   it fails opening /dev/agpgart. Maybe we sometimes loose acceleration after
   a resume, because the modprobing differs from a normal bootup.
   => needs investigation
3. With the i915 driver the contents of the osd overwrite/use the hwcursor. You
   can rebroduce it by e.g. using function key "battery status" and then moving
   the mouse. You will see that the osd will follow the mouse movement.
   Sometimes the hwcursor then fails to update, and disapears - mouse pointer is
   invisable. This does all not happen with swcursor.
   => if we could fix intel_agp/agpgart we should consider to default i915 to
   use software cursor to workaround this.

stefan (sndirsch), maybe you just want to have a look at it, I have such a Samsung (x05).

Ok. I take this one for now.

This should be tested again after switching to the new i810 driver (SUSE 10.2 Alpha). ==> LATER

reopen

*** This bug has been marked as a duplicate of 179773 ***