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.
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-M5b9c63bb91f21f3264e973ff
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
