Running devwsys

The most straightforward way to use devwsys is from 9vx. First, devwsys have to be launched:

user@unix$ devwsys

This will post a 9p server in /tmp/ns.user.:0/wsys (where user is the user name in the unix system and :0 is the current X display). Now, this 9p server can be mounted from 9vx to create new windows. An easy way to access devwsys is setting the wsys environment variable. Then, you will be able to open programs in new windows using window(1) with the -m flag:

term% wsys='#Z/tmp/ns.user.:0/wsys'

term% window -m acme

For a better experience the wctl rc script, included in the util directory of the devwsys distribution, can be used to provide a wctl service. Then, the -m option is not needed any more, new applications will use the namespace of the wctl process:

term% wctl=`{wctl}

post...

term% window acme

Similar commands will work from drawterm(8) too. Inferno, instead, is a bit different. Some files have different names, and cursors have a slight different format. To solve this issue, devwsys will deduce what cursor format is being used depending on what is written to the cursor file, while extra keyboard and pointer files are equivalent to cons and mouse. So, the only required step is to mount devwsys before launching wm(1):

; mount -Ab '#U*/tmp/ns.user.:0/wsys' /dev

; wm/wm

Have fun!

Drawing cats

The main function of the drawing device is to draw the catclock window. This video shows how devwsys can be used for this fundamental task, and even to play sudokus, using 9vx on top of linux.

There are still many thing to be done: resizes are not working, programs segfault when the right mouse button is pressed, anything using fonts will fail and memory is being leaked all over the place. But we can draw cats, everything should get easier now.

Bye bye drawfcall

Devwsys no longer uses an internal Wsysmsg representation. As a matter of fact, drawfcall support has been completely removed. Getting rid of this level of indirection devwsys can become a simpler program. It will only support one interface: a 9p file system.

The drawfcall infrastructure in p9p's devdraw has been verey helpful to get started, but it was starting to get in the way. We want to run devwsys in different environments, any unnecessary complication should be avoided. Mixing the draw and wsys file systems is complex enough already.

Preview release of devwsys

A preliminary version of devwsys is publicly available:

hg clone http://bitbucket.org/yiyus/devwsys-prev/

This version does not have a functional drawing device yet, but can be used to create windows and read input events. Libixp and mk are the only external dependencies required to build. The Inferno drawing libraries are included in the repo.

Running devwsys a 9p server is started (by default in /tmp/ns.$USER.$DISPLAY/wsys). When mounted, a new window is created in the X display, and the following files can be accessed:

• winid: an unique window id.
• label: read or write it to get or set the label of the window.
• mouse: to get mouse and resize events.
• cons: to get keyboard events. Alt is the compose key.
• consctl is only a dummy file. cons is always on rawon mode.
• wsys/n/ gives access to the file system of all the open windows.
• draw/ and draw/new are not functional yet.

Devwsys still needs much more work, but is progressing. There are still many aspects to improve, and more files need to be implemented for rio(4) compatibility. The drawing device is the top priority now.

Libdrawp release

The libdrawp repository is now publicly accessible:

hg clone http://bitbucket.org/yiyus/libdrawp/

For more information about libdrawp, see this post. Let me know if you find the libraries useful or have any problem with them.

Devwsys

Devwsys will be a new program. Its main components will be some libraries from Inferno (libdraw, libmemdraw, libmemlayer and also lib9 and some pieces from other libraries), libixp and a considerable amount of p9p's devdraw code, as well as from the Inferno kernel devices.

The objective of devwsys is simple in its conception: serve a 9p file system similar to that one of rio(4), with the difference that new windows are not created in a rio instance, but in the windowing system of the host (X11). In fact, a devwsys window will be more limited than a rio window, since it will not include any text editing capabilities, they will only be graphical windows (eg. consctl will only be a dummy file, cons will always be on rawon mode).

In the future, it could be convenient to use an alternative server, for example to work with the p9p's devdraw protocol in stdin/out or to replace libixp with something else. In a similar way, although it is not part of this project, it should be possible to use other windowing systems (like OSX, Windows or, if it takes off, Wayland). In order to achieve this goal, devwsys will use the internal message representation of devdraw. 9p messages will be converted into Wsysmsg's and a runmsg function will take care of interpreting this message and perform the relevant (window system agnostic) function calls. If we want to replace libixp we will only need to build the corresponding Wsysmsg from any form the requests take and supply a reply function, and if we want to support other windowing system only the functions used by runmsg will have to be implemented.

Of course, we are not there yet, but are getting a bit closer with every line of code. A very preliminary version of devwsys will be made public at the end of this week, with the basic functionality to create new windows and some support for input events (mouse and cons files), but not drawing yet.

(Not so) portable drawing devices

The quick results obtained with the drawing libraries led me to think that it could be possible to port one of the existing devices without much work. I was wrong.

The devices in 9vx and Inferno are kernel devices and they make use of all the facilities a real kernel gives you. In particular, they use kprocs and chans, which are not obvious to get working in an Unix environment (not without having to add too much code). There is a kproc implementation based in pthreads I have not got my hands on yet, but anyway we want to stay away from threads, because multi-threaded programs and X11 do not play well together. Extracting only the useful bits from these devices is certainly doable, but not an easy job (not particularly difficult, but is not the kind of thing you can try in an afternoon).

Plan9port's device, however, is not a kernel device. It is an external program. It looks like that could make things easier but, in practice, not so much. I have tried but, after writing some sed and ed I realized the task was much larger than I had originally thought (or, should I say, hoped).

So, what is the plan for the wsys device? Writing our own. However, we have nice examples available, so it is not a rewrite from scratch, not at all. Some portions can be taken from p9p, some other portions from Inferno or 9vx. Surely some parts will have to be reworked, refactored or totally rewritten. The idea is to start with something very basic and add features one at a time, always having something we can compile and test. This way, not only we have a better control of the code, it will also help me to understand better how it works and all the involved problems. It will take some time but I hope the result will be worth all that work and, to be honest, being able to compile one of the existing devices with only a few changes would have been too good to be true.

For the moment, this was the last experiment. The following posts will discuss the development of the new device.