From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 17330 invoked from network); 28 Jan 2022 11:38:21 -0000 Received: from tb-ob0.topicbox.com (64.147.108.117) by inbox.vuxu.org with ESMTPUTF8; 28 Jan 2022 11:38:21 -0000 Received: from tb-mx0.topicbox.com (tb-mx0.nyi.icgroup.com [10.90.30.73]) by tb-ob0.topicbox.com (Postfix) with ESMTP id E896138DC5 for ; Fri, 28 Jan 2022 06:38:20 -0500 (EST) (envelope-from bounce.mM5b9c63bb91f21f3264e973ff.r522be890-2105-11eb-b15e-8d699134e1fa@9fans.bounce.topicbox.com) Received: by tb-mx0.topicbox.com (Postfix, from userid 1132) id E4D9213ED9F4; Fri, 28 Jan 2022 06:38:20 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=9fans.net; h=to:subject :message-id:references:in-reply-to:date:mime-version :content-type:content-transfer-encoding:from:list-help:list-id :list-post:list-subscribe:reply-to:list-unsubscribe; s=dkim-1; bh=MIgNinhmT/urSokrkKMqLv+k3o/gR2YIgesR+lFOLuc=; b=UMMphXfi2LtO hNuypzxBULEWBbEwGb5pb3bNPts9x4Ob6F5mwqoxUy5ghMbMvD5RtGtY8eoA+dVY s/9WurbGN7i9EGQJ0YQY5sCC1pr8EVOISYsFsn1zFotwvD6qaggkL/sJzj4lgju+ quSUdhGEpHLLLG/+KIfFIVjtX7OZlek= To: 9fans <9fans@9fans.net> Subject: Re: [9fans] suggestion : new service targets for plan9 Message-Id: <16433698950.b3ce7.20469@composer.9fans.topicbox.com> References: <4F7E620B5C3CAA867792DA6F6DB5DCE7@eigenstate.org> In-Reply-To: <4F7E620B5C3CAA867792DA6F6DB5DCE7@eigenstate.org> Date: Fri, 28 Jan 2022 06:38:15 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=16433698951.0126F.20469 Content-Transfer-Encoding: 7bit Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: c873eadc-802e-11ec-8784-1b869134e1fa Archived-At: =?UTF-8?B?PGh0dHBzOi8vOWZhbnMudG9waWNib3guY29tL2dyb3Vwcy85?= =?UTF-8?B?ZmFucy9UMjUxOGY5ZTRmYzEwZWQwMy1NNWI5YzYzYmI5MWYyMWYzMjY0ZTk3?= =?UTF-8?B?M2ZmPg==?= From: "ibrahim via 9fans" <9fans@9fans.net> List-Help: List-Id: "9fans" <9fans.9fans.net> List-Post: List-Software: Topicbox v0 List-Subscribe: Precedence: list Reply-To: 9fans <9fans@9fans.net> List-Unsubscribe: , Topicbox-Delivery-ID: 2:9fans:437d30aa-c441-11e9-8a57-d036212d11b0:522be890-2105-11eb-b15e-8d699134e1fa:M5b9c63bb91f21f3264e973ff:1:lYpEdzNH8DDzUBRYQy6dCDCrzysWzXlKt0lfJvLNJ2Y --16433698951.0126F.20469 Date: Fri, 28 Jan 2022 06:38:15 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Friday, 28 January 2022, at 6:22 AM, ori wrote: > It'd probably make sense to generalize: 'service=3Dfoo' in plan9.ini could run /bin/^$foo^rc. This is an excerpt for one experimental gdi from profile ... ramfs font =3D /lib/font/bit/lucida/unicode.10.font upas/fs fn cd { builtin cd $* && awd }=C2=A0 # for acme service=3Dkiosk case kiosk echo -n accelerated > '#m/mousectl' echo -n 'res 3' > '#m/mousectl' prompt=3D('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=3D('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 b= efore 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 v= ariable 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 usab= le for both window managers directly using this fbdev and also for devdraw = (memlayer, memdraw). In last instance devdraw does also render to the graph= ics memory so this layer would be shared by both. This extra layer would ma= ke sure that only one application has direct access to the framebuffer whil= e the other gets multiplexed. I did the multiplexing in my window manager f= or 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 a= s 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 real= ly necessary. Those changes would make both window systems benefit by a sha= red 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 =3D initmouse(nil, screen)) =3D=3D nil) sysfatal("%s: %r", argv0); if((kctl =3D initkeyboard(nil)) =3D=3D nil) sysfatal("%s: %r", argv0); pixi_init() ; test_fb () ; draw_fb () ; enum{MOUSE, RESIZE, KEYBD, NONE}; Alt alts[4] =3D { {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 work= s but the code could be simplified by a notification layer which we can def= ine all together. To make things more clear : I have a working kiosk and an experimental window system but those can be i= mproved and I would prefer making those things a general well documented pa= rt of the system. The more people experiment with such an enhancement the m= ore it evolves and the less bugs will remain. I have ideas and I'm sure oth= ers also have ideas so it would be best to share opinions and learn from ea= ch other. I don't like forking a project when I like its progress as I do r= egarding 9front legacy9. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-M5b9c6= 3bb91f21f3264e973ff Delivery options: https://9fans.topicbox.com/groups/9fans/subscription --16433698951.0126F.20469 Date: Fri, 28 Jan 2022 06:38:15 -0500 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Friday, 28 January 2022, at 6:22 AM, ori wr= ote:
It'd probably make sense to g= eneralize: 'service=3Dfoo' in plan9.ini could run /bin/^$foo^rc.

This is an excerpt for one experimental gdi from profile

...
ramfs
font =3D /lib/f= ont/bit/lucida/unicode.10.font
upas/fs
fn c= d { builtin cd $* && awd }  # for acme
service= =3Dkiosk
case kiosk
echo -n accelerated >= ; '#m/mousectl'
echo -n 'res 3' > '#= m/mousectl'
prompt=3D('term% ' ' ')
fn term%{ $* }
# cat /sys/lib/kbmap/de > /d= ev/kbmap
exec /usr/glenda/proj/gdi/gdi
# ex= ec rio -f /lib/font/bit/lucida/unicode.10.font
case termina= l
plumber
echo -n accelerated > '#m/mousec= tl'
echo -n 'res 3' > '#m/mousectl'<= br />
prompt=3D('term% ' ' ')
fn = term%{ $* }
exec rio -f /lib/font/bit/lucida/unicode.10.fon= t
# exec /usr/glenda/proj/gdi/gdi
...
=

I defined kiosk as a service target inside profile an= d by editing profile before starting I can switch between the new window sy= stem 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 wo= uld 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 devi= ce usable for both window managers directly using this fbdev and also for d= evdraw (memlayer, memdraw). In last instance devdraw does also render to th= e graphics memory so this layer would be shared by both. This extra layer w= ould make sure that only one application has direct access to the framebuff= er while the other gets multiplexed. I did the multiplexing in my window ma= nager 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 de= vdraw as well as this dev driver try to write concurently to the video memo= ry. The changes to memlayer memdraw devdraw would be minimalistic but are n= ot really necessary. Those changes would make both window systems benefit b= y a shared code base and improvements in this code base while totally trans= parent 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 =3D initmouse(nil, screen)) =3D=3D nil)
sysfatal("%s: %r", argv0);
if((kctl =3D initkeyboard(nil)) =3D=3D nil)
sysfatal("%s: %r", argv0);
pixi_init() ;
test_fb () ;
draw_fb () ;
enum{MOUSE, RESIZE, KEYBD, NONE};
Alt alts[4] =3D {
{mctl->c, &mouse, CHANRCV},
{mctl->resizec, &resize, CHANRCV},
{kctl->c, &r, CHANRCV},
{nil, nil, CHANEND},
};

Currently I'm doing things for even= t 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.
<= br />
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 su= re others also have ideas so it would be best to share opinions and learn f= rom each other. I don't like forking a project when I like its progress= as I do regarding 9front legacy9.

= --16433698951.0126F.20469--