Problem behoben: Razer DeathAdder Mausrad hat gesponnen

Bei meiner Razer DeathAdder Maus hatte ich seit kurzem das Problem, dass ein Scroll-Down ausgelöst wurde, obwohl ich nach oben gescrollt habe. Besonders auf Websites, auf denen man lange scrollt, ging mir das ganz schön auf die Nerven, als auch bei gewissen Spielen, bei denen das Mausrad eine Funktion erfüllt.

Da die Garantiezeit gerade vorüber war, konnte ich die Maus bedenkenlos aufschrauben, um sie zu reinigen. Der Kreuzschlitzschraubenzieher muss sehr dünn sein, um an die kleinen Schrauben in dem engen Loch dran zu kommen. Dennoch sollte er über einen dicken Griff verfügen, um genügend Kraft aufwenden zu können, denn ich habe noch nie so fest sitzende Schrauben gesehen. Wir mussten zu zweit und mit einer Zange arbeiten, um genügend Kraft aufzubringen. Einen Videoguide zum Öffnen der Razer DeathAdder Maus gibt es auf YouTube.

Das Mausrad zeigte sich total verdreckt. Viele Haare hatten sich um das Mausrad herum aufgewickelt. Ich beseitigte die Haare. In einem anderen guten Artikel zu dieser Maus habe ich gelesen, dass man das Rad auch mit WD-40 Öl schmieren kann, wovon ich aber erst mal abgesehen habe.

Jedenfalls hat die Reinigung der Maus das Problem mit dem verbuggten Mausrad behoben. Eine Reinigung innerhalb der Garantiezeit ist allerdings nicht zu empfehlen. Denn um die Maus aufschrauben zu können muss man das Garantiesiegel durchstoßen.

Fehler im openGL Tutorial von NeHe

Heute versuchte ich, Lesson 06 (Linux version) bezueglich texture mapping des NeHe Tutorials zu openGL auf meinem Rechner an der Uni zu starten.

Ich erhielt beim Starten von lesson6 folgenden Fehler:

Width of Data/lesson6/NeHe.bmp: 139964394242304
Height of Data/lesson6/NeHe.bmp: 139964394242304
Error allocating memory for color-corrected image data

Das Problem war, dass ich unter einem 64-bit Linux arbeite, wie ich in einem Forenbeitrag herausfand:

Also, if we assume that I’m correct in saying that „unsigned long“ is a 64-bit quantity, then reading a 4-byte word would only set half the „long“. You’d need to sign-extend it to make it a 64-bit integer [as it can be negative].

It would probably be better to use a „sized type“, such as a „INT32“ or some other „user defined type“ that can be adjusted to the right size according to what compiler is being used.

Also aenderte ich im image-struct die size Angabe von unsigned long auf int, und es lief.