On Friday, 28 January 2022, at 6:22 AM, ori wrote:
It'd probably make sense to generalize: 'service=foo'
in plan9.ini could run /bin/^$foo^rc.
This is an excerpt for one experimental gdi from profile
...
ramfs
font = /lib/font/bit/lucida/unicode.10.font
upas/fs
fn cd { builtin cd $* && awd } # for acme
service=kiosk
case kiosk
echo -n accelerated > '#m/mousectl'
echo -n 'res 3' > '#m/mousectl'
prompt=('term% ' ' ')
fn term%{ $* }
# cat /sys/lib/kbmap/de > /dev/kbmap
exec /usr/glenda/proj/gdi/gdi
# exec rio -f /lib/font/bit/lucida/unicode.10.font
case terminal
plumber
echo -n accelerated > '#m/mousectl'
echo -n 'res 3' > '#m/mousectl'
prompt=('term% ' ' ')
fn term%{ $* }
exec rio -f /lib/font/bit/lucida/unicode.10.font
# exec /usr/glenda/proj/gdi/gdi
...
I defined kiosk as a service target inside profile and by editing profile before starting I can switch between the new window system and rio both can run inside each other. By defining well known targets like kiosk or desktop aso the compilation would get easier and due to the existing environment variable the running main window system would be known to client apps (even if not necessary)On Friday, 28 January 2022, at 6:22 AM, ori wrote:
Why would another layer be help?
Libmemdraw is not very fast, and profiling+optimization
will be needed to solve that, but I'm not sure what an
additional layer is supposed to do there.
The extra layer would make sharing of the optimized framebuffer device usable for both window managers directly using this fbdev and also for devdraw (memlayer, memdraw). In last instance devdraw does also render to the graphics memory so this layer would be shared by both. This extra layer would make sure that only one application has direct access to the framebuffer while the other gets multiplexed. I did the multiplexing in my window manager for rio so its possible to run my window manager inside rio and vice versa. The alternative would be a parallel fbdev with the risk that both devdraw as well as this dev driver try to write concurently to the video memory. The changes to memlayer memdraw devdraw would be minimalistic but are not really necessary. Those changes would make both window systems benefit by a shared code base and improvements in this code base while totally transparent for any application running on the system.
On Friday, 28 January 2022, at 6:22 AM, ori wrote:
Sure. It fits -- same place as kbdfs -- but someone
needs to come up with the event encoding, write the
'touchfs', and implement the readers that toss events
down channels.
Nothing insurmountable, just needs someone who cares
about it to roll up their sleeves and write code.
if(initdraw(nil, nil, argv0) < 0)
sysfatal("%s: %r", argv0);
if((mctl = initmouse(nil, screen)) == nil)
sysfatal("%s: %r", argv0);
if((kctl = initkeyboard(nil)) == nil)
sysfatal("%s: %r", argv0);
pixi_init() ;
test_fb () ;
draw_fb () ;
enum{MOUSE, RESIZE, KEYBD, NONE};
Alt alts[4] = {
{mctl->c, &mouse, CHANRCV},
{mctl->resizec, &resize, CHANRCV},
{kctl->c, &r, CHANRCV},
{nil, nil, CHANEND},
};
Currently I'm doing things for event handling like in a rio app and it works but the code could be simplified by a notification layer which we can define all together.
To make things more clear :
I have a working kiosk and an experimental window system but those can be improved and I would prefer making those things a general well documented part of the system. The more people experiment with such an enhancement the more it evolves and the less bugs will remain. I have ideas and I'm sure others also have ideas so it would be best to share opinions and learn from each other. I don't like forking a project when I like its progress as I do regarding 9front legacy9.