[prev in list] [next in list] [prev in thread] [next in thread] 

List:       suse-blinux-d
Subject:    Re: [blinux-de] Pfeiltasten funktionieren auf einemal nicht mehr :(
From:       Klaus Knopper <knopper () knopper ! net>
Date:       2008-09-03 19:31:21
Message-ID: 20080903193121.GH20114 () knopper ! net
[Download RAW message or body]

Hi Halim,

On Wed, Sep 03, 2008 at 06:54:10PM +0200, Halim Sahin wrote:
> Hallo,
> On Mi, Sep 03, 2008 at 05:55:07 +0200, Klaus Knopper wrote:
> > Das beobachtete Phänomen trat so ähnlich bei uns auch auf, daher habe
> > ich die Cursorrouting-Funktion in SBL gepatcht, seither geht's.
> 
> Lieber Klaus,
> Du vermengst hier glaub ich mehrere dinge!
> Siehe Dir mal den 
> Bug#497568
> An.
> Das von Christian beschriebene Problem haben nicht sbl benutzer mit
> kernel 2.6.26 auch.
> Das Problem scheint mit der Nutzung diverse X Programme
> zusammenzuhängen.

Also ich habe aus seiner Mail nicht herausgelesen, das es sich um ein
Problem mit X handelt. Wo steht das?

> Das entfernen von wichtigen Funktionen kann eigentlich nicht zum Ziel
> führen.

Welcher "essentieller Funktionen"? Das aktuelle SBL verursacht einen
internen Fehler, da sich das Programm jedemal im Speicher "vermehrt",
wenn eine Cursorrouting-Taste gedrückt wird, um es einmal für
Nicht-Techniker auszudrücken.

Mein Patch ersetzt dies durch einen einfachen Funktionsaufruf. Dadurch
wird das Cursorrouting bi uns überhaupt erst einmal brauchbar. Vorher
stürzte es einfach ur ab, und zwar jedesmal, wenn eine
Cursorrouting-Tsate gedrückt wurde. Ich weiß, bei dir nicht. Du hast ja
auch eine andere Braillezeile ubnd verwendest eine andere Sprachausgbe,
und überhaupt ist dein System anders. Aber bei uns war es eben so, und
durch den Patch geht es jetzt. Ich habe keine Funktionalität
"weggepatcht".

> Ich hab Deinen patch probiert und festgestellt, das sbl dadurch
> unbrauchbar wird, was das routing angeht.

In welcher Form äußert sich das? Bei uns springt der cursor an die
gewünschte Stelle, und es kommt nicht zu einem Absturz der Sprachaugabe.
Vor dem Patch ging beides nicht. Das ist die konkrete Erfahrung. Wenn
durch den Patch bei dir ein Problem auftritt, sollte es genau
beschrieben werden, damit man es beheben kann. Marco hat schon
angekündigt, dass er generell das Cursorrouting überarbeiten möchte, da
es auch für ihn nicht richtig nachvollziehbarer, alter Code ist. Das
sehr ich genauso. In der derzeitigen Form wundert mich sowohl, das es
bei dir jemals fuinktioniert hat, als auch dass es "langsamer" werden
sollte, wenn man den fork() weglässt und den Cursor RICHTIG
positioniert.

> Clickt man auf einen bereich, wo der cursor nicht hinkommen kann,oder
> auch mehrfach an irgendeine stelle blockiert die Funktion (ohne fork).

Bei uns passiert das nicht. Die Frage ist also, warum es bei dir
passiert. In welchem Programm, beispielsweise?

> Wenn dann innerhalb dieses Zeitraumes versucht wird über die Tastatur
> was zu schreiben, Dann 
> zieht sbl den cursor immer weg, bis die blockierende Abarbeitung vorbei
> ist.
> Das ist so sicher kein Weg.

Wenn das bei dir so passiert, dann ist es ein Fehler, der behoben werden
muss. Ich kann dir sagen, was in der fork()-Version passiert, wenn eine
der ncurses-Funktionen blockiert, i.e. der Cursor sich nicht
positionieren lassen will. Dann läuft ein Timer ab, der das laufende
Programm killt (kein Witz), und der Programmfluss geht zurück zum
aufrufenden Thread. DAS ist sicher keine elegante Lösung, stattdessen
sollte erst gar nicht versucht werden, mit falschen x/y-Koordinaten zu
positionieren, ODER es müssen non-blocking Aufrufe verwendet werden.

Der fork war und ist an dieser Stelle auf jeden Fall falsch, da er sehr
viele Seiteneffekte hat (Dateideskriptoren werden geschlossen, obwohl
der Hauptprozess noch darauf zugreift, Variablen werden verdoppelt, das
ganze System wird instabil). Daher meine Verwunderung, warum es mit dem
fork() überhaupt jemals funktionieren konnte.

> BTW. der code zum routing stammt von einem alten brltty und wird heute
> noch verwendet.

Sagte Marco auch, und ich finde, es ist Zeit, den Code loszuwerden und
durch etwas gesunderes zu ersetzen. Vor allem, weil keiner mehr
versteht, was der Code eigentlich genau macht.  Das was er machen soll,
lässt sich sicher mit viel weniger Zeilen Code programmieren.

> Was Deine Probleme mit sbl angeht:
> Hast Du mittlerweile eine livecd, die bei Dir genau das Problem
> reproduziert?

Das Problem sehe ich durch den Patch als vorerst gelöst an, der Feher
lag beim fork() nebst Schließen von Dateideskriptoren, die noch in
Benutzung waren (nämlich durch die laufende Sprachausgabe), daher ist
hier kein Debugging mehr notwendig. Der durch die Behebung dieses
Fehlers zutage getretene systematische Fehler bei der Verwendung von
Calls, die unter bestimmten Umständen (die ich hier noch nicht in der
von dir gemeldeten Form nachvollziehen kann) ist der nchstem, den es zu
beheben gilt.

Einen Timer ablaufen zu lassen und das Programm zu terminieren, wenn es
blockiert, kann ja wohl keine erstzunehmende Dauerlösung sein. Eine
Cursorpositionierung muss auch ohne fork() nicht-blockierend möglich
sein, das machen doch tausende von Konsolenprogrammen, warum soll sbl
das nicht können?


Viele Grüße
-Klaus
-- 
To unsubscribe, e-mail: blinux-de+unsubscribe@opensuse.org
For additional commands, e-mail: blinux-de+help@opensuse.org

[prev in list] [next in list] [prev in thread] [next in thread]