We know start just in time.
Hello, I am Erin.
You can see here and this is my first time I'm giving a talk.
So let's begin talking.
Do you want to talk about Wyland composers?
So here you can, I'm Erin.
I work.
It doesn't make you can see my work.
Get up if you want to see stuff.
There is source code related to this talk on there as well.
If you want to stalk me the website where you can text me probably.
So let's begin.
I have to say this claimer.
I will be talking about Wyland.
I'm not paid by IBM or Red Hat to chill it.
I also do not use any narrative AI.
So you will see that.
Graphic design is my passion.
And no license.
Let's see.
Okay.
Long time ago before probably I was even born.
There was only X ever on the next.
Even before X11 X3 86.
And you had this.
One big X11 server.
You had to.
You used OST one.
More that.
Take your shaman art application,
communicate it and use it stay.
Un Hugh.
But what you from the file.
Top team.
15.
And you were starting on the set.
There were a lot of restructuring done.
We have now in the kernel DRM responsible for rendering stuff.
You have a major project implementing graphics APIs.
Programs can use cameras for modes setting.
So you have to have a kernel for events,
excel and so to use that.
But yeah, you still have the separate window manager
compositor application thing running.
We have the one big Excel 11 server, which
is designed from the 80s.
I've read.
Does anyone know the handbook for Unix Hs?
Yeah, even then, Excel was criticized.
So nothing new.
But then we got this island.
And yeah, one compositor is not one well-in-compositor.
Just the arrow between the well-in-compositor
and application is the island.
This is probably our normal desktop stack,
is the desktop stack I run on this computer.
But as we will see later, you don't have to run it in this way.
So we eliminated all the separate components.
There's the big x-server with the old Arcane APIs,
and just you think this?
So first of all, desktop step on embedded.
Like I said before, I work a tourist.
We do open source routers.
And we have a new one.
There is a display.
There is a depart.
You can use for navigation.
It's just arrow keys.
And by the way, the back button from the left,
like if you look on the front is F1 key.
And it runs a tourist OS, which is,
this is then based on OpenWRT.
And on OpenWRT, there are in-many things related
to a GUI.
Actually, they have a repository with GUI stuff.
But both of the things are outdated or missing.
I think the wild protocols are like six years old.
I couldn't even run a terminal on it.
And there is also no proper user thing.
There is a lip you have zero, and you can look at the repo
if you laugh conspiracy theories about system D.
There is, like, under reach me, a nice way to explain,
explaining that you def was created in this way.
So it's hard for people to use and some vendor locking and stuff.
It's kind of fun.
So when I went to Saudi working at a tourist,
it's quite recent.
It under half a year ago.
I go to task with working for the display control thing.
And we have a graphical application.
It's using the slint to rust.
We fry, and it uses directly DRM for rendering.
One thing, the back end is bugged, or at least was at a time.
And it really, really ate all the CPU stickers.
And also, we wanted to implement an easterack in a form of a little mini game.
That was an issue, because implementing in the GUI application of slint,
something which isn't made of the basic components is painful.
Also, for conference in Proachlinux days,
we wanted to demo a doom, because can it run doom.
And all the things, and as we are friendly towards user customization,
we wanted a nice way for users to actually run their own programs on the display.
And doing that with DRM is painful.
You have to use a GUI tool kit, which supports that thing.
If you want to use that, an application switching is literal hell.
So I was like, I will make a violent compositor.
So the control program for the screen is called PicoCurs.
So I named PicoCurs.
It's just like over a thousand lines of rust.
It uses the smithy library, and it's pretty lightweight.
It currently supports running only one window, like one window,
but it will just stack them on top of each other.
You can easily switch them, which I would like to fix at some point.
Currently, currently, we just run one program on it.
It's an easter egg, but you can 41.
And so I have to probably say that we make a gaming router.
This is a pretty general purpose compositor still.
So we can look at more domain specific use cases.
Do you notice computer?
Me and the friend we went to a store, like when I saw all stuff,
and I saw this computer, it's really pretty.
So I bought it home, installed a Camaro Linux on it.
It supports a filter to be power PC, and unlike Debian, the support is actually working.
The last time I tried Debian, installing network manager,
I wanted to uninstall system D, and the carnal as well.
It was kind of fun.
And it runs, it has the ATA rage 128 Pro GPUs,
ATP advanced graphic pot.
And I found out that there is no really Debian driver in the carnal for it.
I just have the frame buffer device.
I could use the Debian driver for the open firmware frame buffer,
but it wasn't doing well.
So I was like, yeah, okay, I again use this midi library,
and just write a compositor.
And the nice thing about Wellen is very easy compositor-nesting.
You just implement your compositor with a violin as a back end.
So I wrote it, it's not complete yet.
I had some issues with 32-bit atomics on the platform.
But yeah, and I can run an optional inside it.
Note that I want to run a good optional on that computer.
So, for example, there is a WAPAP.
Anyone here uses Excel the forwarding over SSH.
Yeah, the fun thing is, many people say, oh, we don't have a violin.
We can't do Excel the forwarding.
Like, we would have to copy the entire frame buffer to a computer.
Okay, you do that mostly with Excel then as well,
because maybe accept X-term and all the OG X software.
As far as I know, all the GUI frameworks we nowadays use,
still just take a frame buffer, and render their things themselves.
So you have to do it anyways.
So there is a WAPAPAP which forwards violin messages,
series of buffers.
We use it with development because I have the router lying on the desk.
I wrote a really cursed script for a cross-compiling it.
And then it just runs over SSH, and I have on my screen can interact with it.
Sadly, as I don't think I managed to get FFM,
they're running on it well, so it's a really slow.
Okay, so next thing.
When I first started programming,
I went to a programming course,
and we were using bold and delf-y.
And it had a nice thing for a GUI design.
When I then went to using things at Linux,
for a GDK2 and GDK3,
there were graphic designers, you can just click here, stuff in.
But when GDK4 came, it was not very well done.
And we had this project called Kambalash.
I don't know how to read it, sorry.
And I was kind of surprised that it renders the UI file.
You made it.
But just running a one-composator as a GDK widget, using a casilda.
So you can embed violin in your programming, say, if you want.
And so, laughing from this category,
I recently read on foreign eggs that I don't know who proposed that
to have an option to switch kernel virtual terminal,
like on runtime.
That's fedora in the next release was to use KMS,
a con, instead of BT102 emulated by the Linux hurdle.
Well, there were plans for that, like, I don't know,
read these milling 13 years ago.
And there were many proposals how to do it.
And one of them was running a quantum compositor as the root thing.
If you study the violin docs, there are actually some entries
about certain called assistant compositor.
It was funny I've never found anything else about it,
except on the valent, I don't know, specification page,
where you could then deprecate the VITs entirely,
and just use the violin compositor if you just want to have a console.
You can just add a no-food, like we do on the OmniaNG.
If you run from the menu application, which requires a console,
it's setting for it, it's supposed to food.
I'm old, well, that's pretend.
And you can add all you have the valent compositor
nesting, and you could run your normal session compositor inside it.
I wouldn't recommend it nowadays, because both compositors
are really designed to run on your student directly.
And the valent backends are, most of our development.
And also, it would require having a violin compositor
for the entire system, which just a lot of stuff.
So the idea really didn't get well, but yeah, we can see an example of that.
So no, I just have to wait to just slide a little bit,
press well.
Again, we can look at how we can implement one.
Anyone here tried to make a violin compositor?
Yeah, so yeah, several options.
If we do not want to make it completely ourselves,
actually, I know a person who went to make some valent library, which
I don't know pre-allocated some buffers.
And then except for that needed, like for the new client and stuff,
I tried to minimize that.
I don't know how the project went.
But yeah, I used Smithy, written in Rust,
it used for nearly cosmic or RP comp.
It's pretty easy to use.
So you can create a compositor object and just implement traits,
or to which implement the protocol and kind of works.
Then you have probably one of the, all the ones,
WL routes, originally made for a sway.
This is in C, and it's also used in the Casilla, in the widget,
or a fock.
Anyone here uses osmarched osmarched osmarched osmarched osmarched
generally links, just with desktop Linux and phone,
just compositor use in a flash.
Or one of the OG ones, the Western reference implementation for that.
It's, I think also, it's nice if you want to do some more.
Like you want a compositor, which is kind of done,
and you just want to have some your own logic on top of that.
So I had that it's also used in embedded stuff.
Remember the canonical thing that kind of like it was like,
oh yeah, let's remember how would it use a space?
We will make our own graphics on protocol.
We will make our own desktop environment, which
didn't really go well, they made this by protocol called mere.
I think I tried it once.
Really, that was useful, but they turned it into violent compositor now.
Use in miracle and mirror way, and for my head,
it's more like a complete product.
You just implement some policies.
So probably a developed experience should be more close to
making specific window managers for violent,
than just making their own compositor from the scratch.
And for what to say about the core, about a violent protocol
on the embedded, what's nice about that is,
we have just these protocols, which are the Correlan.
That's what makes the base of violent.
It's not really much.
Nesting compositor, I did it was like 649 of rust.
You don't have to when you make embedded things to use it directly.
You can just shove a little violent compositor,
which is just one thing you need.
You don't need to run entire excel, have on it.
And I don't think there is like packaging for OpenWR
to have X11, and I am not going to make it.
For sure, this was pretty much.
Easier thing, but if you want to run something on it,
most applications just won't work.
Like for terminal requires some extensions.
So, we also have some extra extensions,
like the Excel, which implements the notion of window wing and stuff.
We've deprecated a WL shell one.
Then you have extensions like session lock.
Everom managed to use some lock external lock program for a violent session
when it crashes, and some compositors just like show dark red.
Something, it's implemented way, then when you lock a session,
the one compositor itself should be locked.
So, when you lock crashes, it should not unlock your session.
But it's very unfortunate.
You also have extensions like Linux, the MABF,
for making a buffer for memory access with your, for example.
Graphics devices, and a controversial,
ex-digit decoration manager, which doesn't implement,
I think it's one of the few who do not implement it.
I mean, I had the code basis with Cursed for that,
or compositor specifically like Lair Shell,
which loves you to make things like panels, background,
using external programs.
We implement in a PCom per decoration manager,
but what it all does is a telling the program.
Here we are, I will draw several side decorations,
and just not proceeding not doing it.
Because you probably do not want to waste space
on the little screen decoration of the window.
Okay, so here you can see you can pick any back and view.
I actually want to put out, because, again, it's just a protocol.
You have to do some presenting, like,
allocate in buffers, we just use, I think,
at least in the library called Dumbuffers,
because we do not have a GPU on the router.
You can do rendering, using, yeah, again, anything,
maybe someone could do direct access, that will be funny.
We use a pixelan, or just to solve to renderization,
input management, and an ocean of seed.
When you have, like, some keyboard to display at the devices,
which was actually one of the problems
of the system composers, because, while on,
can work with, like, screen keyboard mouse,
but, what about audio device?
That's managed in, such a seed management thing,
like log in D, but, it's not.
So, I hope I wasn't too quick, but,
who's 25 minutes, so now we have time for questions.
Thank you.
Oh, you have to answer.
Yeah, of course.
Your question?
Yes, can you hear me?
Yes, I can.
One question I have is, we have a lacking sufficient replacement
for XRDP, which implements something, like,
multi-seed remote terminal server.
Is a compositor thinkable that could implement that?
I didn't hear you, how can you please be a little louder, I?
Um, multi-seed remote terminal server, running on a headless machine,
what kind of compositor would be thinkable to implement this?
Um, multi-seed things.
I mean, I wanted to do some fun with multi-seed,
writing my own compositor to implement multi-seed stuff.
Because, like, one of the annoying things you can do on Windows,
not annoying nice things, you can do in Windows, but it's annoying,
it doesn't, one Linux is, is a session hand-off,
like, you can just move the session to RDP.
Yeah, so, um, yeah, uh, I don't think there are any things for that,
at least right now.
The most mature support is for, um,
I don't think there are any things for that, at least right now.
The most mature support is for,
the most mature support is for RDP stuff is GNOME,
which you can actually get a login and start a new session,
but you can just not do one session.
So, if you want to log in as your user, you have to kill it.
That's, uh, not a nice one, and, uh, I hope in the future we actually get some support.
Is one of the things the system level compositor would solve for a nice?
Okay, any more questions?
Yeah.
Okay, right before.
You mentioned small devices, right?
Like, like, those emited routers.
What would you recommend for, like, Raspberry Pi zero class of device,
with some, uh, SPI small display?
And it should be like single, single screen application, single window application,
like on a small screen.
That would start automatically.
I don't need any login.
I don't need to authenticate the user.
I just need to basically start a small device and display some application,
and take input from the user.
What kind of setup would you recommend?
Set up in terms of, uh,
in way, well, and basically, how to set, how to build this application?
Well, what we do, at least on our routers, you can, by the way, look at the demo, we have a stand here.
You can play doing with it.
Well, we just run a system.
There is an inscript.
It runs the compositor.
Well, which libraries?
Because I, I checked basically what is available, and it's,
and it also is that, like, a dozen of different names, which are completely not telling.
Well, depends.
So we don't look our own one called, uh, peak comp.
It's open source.
You can use it.
It should be fine.
There are also things like cage, which also implement similar things for
kiosk, like deployments.
That could also work.
But, uh, could we probably sit somewhere together and actually
exchange some contacts?
Because it's difficult to talk.
Any more questions or, uh,
uh,