ich hatte gerade die Schnaps-Idee[5], einen X11-Client zu
implementieren, der keine XLib oder XCB oder irgend etwas darauf
aufsetzendes benutzt, sondern direkt das (Datenstrom-)Protokoll
implementiert.[6]
In Wikipedia [1] habe ich eine �berblicks-Beschreibung gefunden, aber
nirgendwo gibt es Details zum Protokoll selbst.
Das beste, was ich nach ein paar Stunden suchen finden konnte, war
RFC 1013 [2] von 1987, aber das ist an den Stellen, die ich bisher
gelesen habe, ziemlich schwammig, teilweise widerspr�chlich [3] und sagt
auch:
This document does not attempt to define precise formats or bit
encodings.
Aber gerade diese Bit-Encodings brauche ich doch. Oder?
Auf X.org findet sich offenbar auch kein bisschen einer Spezifikation
(oder ich bin zu dumm zum Suchen).
Der Wikipedia-Artikel gibt noch ein Buch an [4], was ich mir mal
anschauen werde (unsere Uni-Bibliothek hat eines von den Autoren aus
1990/1992, das so �hnlich hei�t, vielleicht eine fr�here Ausgabe des
genannten).
Ansonsten: Kennt jemand eine im Netz zug�ngliche Spezifikation des
Protokolls (oder auch ein anderes Buch, welches ich vielleicht in meiner
Bibliothek finde) oder muss ich mich da wirklich durch die Quellen von
XLib und Co (oder eines der Server) qu�len?
Gr��e
Paul
[1] http://en.wikipedia.org/wiki/X_Window_System_core_protocol
[2] z.B. http://tools.ietf.org/html/rfc1013
[3] Beispiel:
Error Format
Error reports are 32 bytes long. Every error includes an 8-bit error
code. Error codes 128 through 255 are reserved for extensions. Every
error also includes the major and minor opcodes of the failed
request, and the least significant 16 bits of the sequence number of
the request. For the following errors (see Section 5), the failing
resource id is also returned: Colormap, Cursor, Drawable, Font,
GContext, IDChoice, Pixmap, and Window. For Atom errors, the failing
atom is returned. For Value errors, the failing value is returned.
Other core errors return no additional data. Unused bytes within
an error are not guaranteed to be zero.
Also, die insgesamt 32 Bits enthalten 8 Bit f�r den Fehler-Code, 8+8=16
Bit des Opcodes, 16 Bit f�r die Sequenznummer und in einigen F�llen noch
zus�tzlich eine 32-Bit-Resourcen-ID oder ein (32 Bit-)Atom (oder ein
"Value", da habe ich noch nicht nachgesehen, was das ist). Das geht
nicht auf.
[4] Robert W. Scheifler and James Gettys: X Window System: Core and
extension protocols, ...
[5] Anhand der mir zur Verf�gung stehenden Freizeit wird da sowieso
nichts Funktionierendes daraus, jedenfalls in den n�chsten Jahren. Ich
wollte aber mal etwas rumspielen.
[6] Die Idee ist, ein Subset von java.awt.Toolkit direkt auf dem
X-Protokoll (via Socket o.�.) zu implementieren, um so eine "pure
Java"-Implementation f�r die Grafikoberfl�che zu haben. Ist aber nicht
wirklich relevant f�r die Frage.
> ich hatte gerade die Schnaps-Idee[5], einen X11-Client zu
> implementieren, der keine XLib oder XCB oder irgend etwas darauf
> aufsetzendes benutzt, sondern direkt das (Datenstrom-)Protokoll
> implementiert.[6]
>
> In Wikipedia [1] habe ich eine �berblicks-Beschreibung gefunden, aber
> nirgendwo gibt es Details zum Protokoll selbst.
>
> Das beste, was ich nach ein paar Stunden suchen finden konnte, war
> RFC 1013 [2] von 1987, aber das ist an den Stellen, die ich bisher
> gelesen habe, ziemlich schwammig, teilweise widerspr�chlich [3] und
> sagt auch:
>
> This document does not attempt to define precise formats or bit
> encodings.
>
> Aber gerade diese Bit-Encodings brauche ich doch. Oder?
>
> Auf X.org findet sich offenbar auch kein bisschen einer Spezifikation
> (oder ich bin zu dumm zum Suchen).
http://cgit.freedesktop.org/xorg/doc/xorg-docs/tree/specs ist nicht das,
was du suchst?
Florian
--
<http://www.florian-diesch.de/software/easygconf/>
Ja, schon etwas besser. Nach einigen Mühen habe ich aus den Daten
unter XProtocol eine x11.pdf erstellen können, die in ihrem Anhang B
scheinbar auch das Binärprotokoll beschreibt. (Die sonstigen Daten
bekomme
ich nicht verarbeitet, hoffentlich brauche ich die nicht.)
Danke!
Paul
PS: Ich hatte eigentlich an irgend etwas direkt lesbares/surfbares
gedacht,
keinen roff-Quelltext, aber das ist besser als nichts.
> [6] Die Idee ist, ein Subset von java.awt.Toolkit direkt auf dem
> X-Protokoll (via Socket o.�.) zu implementieren, um so eine "pure
> Java"-Implementation f�r die Grafikoberfl�che zu haben. Ist aber nicht
> wirklich relevant f�r die Frage.
Das funktioniert nicht, weil Java von Haus aus keine UNIX Domain
Sockets kennt (au�er f�r den Management Agent, aber die Sockets werden
nicht an Java-Code weitergereicht).
Ansonsten sollte XCB die Spezifikation in maschinenlesbarer Form
enthalten, aus der Du Java-Code erzeugen k�nntest. Das sieht z.B. so
aus:
<request name="UnmapWindow" opcode="10">
<pad bytes="1" />
<field type="WINDOW" name="window" />
</request>
Du bist aber, glaube ich, nicht der erste, der dies vorhat.
> Florian Weimer <f...@deneb.enyo.de> schrieb:
>> * Paul Ebermann:
>>
>>> [6] Die Idee ist, ein Subset von java.awt.Toolkit direkt auf dem
>>> X-Protokoll (via Socket o.ä.) zu implementieren, um so eine "pure
>>> Java"-Implementation für die Grafikoberfläche zu haben. Ist aber nicht
>>> wirklich relevant für die Frage.
>>
>> Das funktioniert nicht, weil Java von Haus aus keine UNIX Domain
>> Sockets kennt (außer für den Management Agent, aber die Sockets werden
>> nicht an Java-Code weitergereicht).
>
> Und? Wieso sollte es nicht reichen, via TCP/IP mit dem X-Server zu
> kommunizieren?
Sollte gehen, die ursprüngliche Lisp-Implementierung des X-Protokolls
kann das auch, warum sollte es mit Java nicht gehen? Neuere
Implementierungen bauen allerdings auf der Xlib auf, u.a. aus
Performance-Gründen. In GNU clisp z.B. kann man beim configure zwischen
den beiden CLX-Versionen auswählen.
Aber was mich bei der Gelegenheit interessieren würde: der Socket wird
doch durch eine Datei repräsentiert, z.B. /tmp/.X11-unix/X0. Ist es
nicht möglich, diese mit Java zu benutzen, um mit dem X-Server zu
kommunizieren? Der Sinn der Abstrahierung durch Dateien ist doch, dass
man alles über Read- und Write-Operationen machen kann. Übersehe ich da
etwas?
Jörg
>> Das funktioniert nicht, weil Java von Haus aus keine UNIX Domain
>> Sockets kennt (au�er f�r den Management Agent, aber die Sockets werden
>> nicht an Java-Code weitergereicht).
>
> Und? Wieso sollte es nicht reichen, via TCP/IP mit dem X-Server zu
> kommunizieren?
Weil das h�ufig abgeschaltet ist. Gut, man k�nnte sich per SSH auf
localhost mit X11-Forwarding verbinden, aber dann ist es wohl
einfacher, einen Perl-"Einzeiler" aufzurufen, der das umleitet.
Ich glaube, das Problem l�sst sich umgehen (entweder den Server passend
konfigurieren -- schlie�lich wurde X11 ja schon als Netzprotokoll
konzipiert, in der Spec steht auch, welche TCP-Ports zu nehmen sind --,
oder schauen, dass man doch irgendwie an die Unix-Sockets rankommt, wie
J�rg vorschlug.)
Es gibt ja auch X-Server in Java, die auch unter Windows laufen, wo es
keine Unix-Sockets gibt (sondern nur TCP an localhost).
Das ist eher so ein Hobby-Projekt ohne direkten Anwendungsbezug, um
etwas �ber X11 (und AWT) zu lernen, es muss nicht unbedingt mit jeder in
der Praxis vorhandenen Server-Konfiguration funktionieren.
> Ansonsten sollte XCB die Spezifikation in maschinenlesbarer Form
> enthalten, aus der Du Java-Code erzeugen k�nntest. Das sieht z.B. so
> aus:
>
> <request name="UnmapWindow" opcode="10">
> <pad bytes="1" />
> <field type="WINDOW" name="window" />
> </request>
Hmm, klingt interessant, werde ich mir mal ansehen. Dann muss ich nicht
alles abtippen :-)
> Du bist aber, glaube ich, nicht der erste, der dies vorhat.
Vielleicht dann aber der erste, dem es gelingt.
Danke f�r den Hinweis.
Paul