Working on extending displayz to other platforms.

[shymega]

Hi,

I'm working on a Rust, cross-platform (Windows, macOS, Linux/BSD) profile-based display output manager. It's event-based but also can be controlled with JSON-RPC.

displayz looks perfect for Windows, but I found myself duplicating efforts in my usage of this crate.

I thought, maybe, it might be a good idea to work on creating a generic DisplayOutput trait for displayz, that, when combined with the target_os attribute, can provide platform-specific implementations of the display outputs.

To give you an idea of how I picture a DisplayOutput trait, here's some code I wrote, and then realized I was duplicating efforts, for automon:

pub type Resolution = (usize, usize);
pub type Position = (usize, usize);

pub trait DisplayOutput {
    pub fn is_primary(&self) -> bool;
    pub fn is_active(&self) -> bool;
    pub fn get_pos(&self) -> Position;
    pub fn get_res(&self) -> Resolution;
}

I'd really like to work on adding the modern API (but also maintaining backwards-compatibility, if possible) with you, and extending the scope of displayz to macOS, Linux, and BSD.

What do you think?

Have a great weekend! :)

[michidk]

Hi,

sounds like a cool project, and maybe even what I initially intended for displayz to become!

I like the idea of making displayz cross-platform - though I don't have the time to implement this right now. If you want to go for it, feel free to open a PR; I am quite open for this change and will continue to support the Windows part of displayz.

Not sure if the display models of other OS are similar to the Windows one (I would guess not), so abstracting this could be quite challenging.

Cheers

[shymega]

@michidk I've pushed my branch to my fork and created a draft PR to collab on.

I wasn't sure what API you wanted to use for #1, so I need some input before I work on abstracting it away. The abstracts are currently in crate::common. It's very barebones right now and needs documenting.

I wanted a cross-platform display output manager, and with autorandr/kanshi, I felt two configs were duplicating the same purpose. And then I thought, I dual-boot with Windows, so why not make a unified manager? Made sense to me.

The display models are vaguely similar on Linux - I don't own a Mac.

[michidk]

I wasn't sure what API you wanted to use for #1, so I need some input before I work on abstracting it away. The abstracts are currently in crate::common. It's very barebones right now and needs documenting.

Don't worry regarding #1. I have to investigate this first, but I think it has not changed too much.

The display models are vaguely similar on Linux - I don't own a Mac.

Then let's focus on Linux and Windows.

I added some comments to your draft PR.

[Shemnei]

Hi @shymega / @michidk

Just chiming in to say great work so far, the proposal looks nice.

Some additional input from me, i like the central trait which all os/managers share. If any of them have specific functions which is specific to that os, we could structure it like the std library has it with e.g. metadata.

I might be interested in doing the linux/x11 implementation if that is ok with you @shymega. This might be just the thing i need for my personal project :)

[Shemnei]

Also i don't know if that would be in the scope of this issue/pr, but i would also like to have a "write" api.

pub trait DisplayXXX {
    fn set_active(&mut self) -> Result<(), ...>;
    fn set_resolution(&mut self, resolution: (usize, usize))

    ...
}

[shymega]

Hi @shymega / @michidk

Just chiming in to say great work so far, the proposal looks nice.

Some additional input from me, i like the central trait which all os/managers share. If any of them have specific functions which is specific to that os, we could structure it like the std library has it with e.g. metadata.

I might be interested in doing the linux/x11 implementation if that is ok with you @shymega. This might be just the thing i need for my personal project :)

Thank you, I like the idea of that std trait approach. We could definitely do something like that, but the idea behind my proposal was for a deterministic API exposed on supported platforms, that doesn't require special handling. Although I suppose that is a tight requirement, so I'm not necessarily opposed to Ext traits.

With regards to Linux/X11, you can see in 043a77b, there's flags for X11 and Wayland. I'm open to you working on X11 - I can grant you access to a branch on my fork, where I can test your changes, and rebase them into the refactor branch - if that works for you.

You should be able to see the abstractions in the linux subdirectory. It would be nice to support the BSDs, but that's at another stage. I think BSDs don't use Wayland, so perhaps I should rename the linux subdirectory.

[shymega]

Also i don't know if that would be in the scope of this issue/pr, but i would also like to have a "write" api.

pub trait DisplayXXX {
    fn set_active(&mut self) -> Result<(), ...>;
    fn set_resolution(&mut self, resolution: (usize, usize))

    ...
}

I think it is within the scope. I would be open to having this available in the API, but maybe we should focus on the "Read" API first, then writing.

[shymega]

Turns out FreeBSD supports Wayland, so I've renamed linux module -> unix, and updated the cfg attrs & Cargo.

I'm currently working on Wayland support. I'm using this tool (Shikane) as a guidelines, but not all of it. It's something I took inspiration from, as well as kanshi for my display output manager.

[shymega]

OK, so I rebased the PR a little, gonna squash some things soon.

@michidk @Shemnei I've granted you both access to my fork as collaborators. Please let me know if you rebase on the refactor branch so I can pull those changes in.

I've got rust-analyzer working with the Wayland crate, so I can begin adding the implementation. I need some input on the common API, so it's consistent across macOS (I know that's not being worked on right now), Unix (Linux/BSDs), and Windows.

Thanks!

[shymega]

Sorry, haven't worked on this for a bit. I'm trying to decide on the best way to define the common API module. I'm also working on a cross-platform WM. This fits in well with displayz, automon - I'm aiming for tight integration.

[shymega]

Update from my end - I've recently discovered that some, but not all compositors, use a different set of APIs. I've found that wlroots has the WLR output management protocols - that's one. Then, there's KDE and GNOME. KDE have Rust bindings; haven't found any for GNOME yet.

I'm wondering if there's more upstream work that needs to happen...