You can abuse an unconnected output for this. Assume you're on a laptop and the internal screen is LVDS1 and you have another connector called HDMI1.

Run xrandr to see the current configuration, pick the desired resolution for the second screen from the LVDS1 list and run "xrandr --addmode HDMI1 1920x1080" to tell X11 that that output supports that resolution, then do "xrandr --output HDMI1 --mode 1920x1080 --right-of LVDS1". This should now have extended your desktop and with a bit of luck you can share that screen with Deskreen. I've used that trick with x11vnc in the past at least. (If Deskteen supports sharing arbitrary regions of your screen you can even skip the whole output fakery and just make your virtual screen larger than your display using --fb, but that's a little fragile since most software assumes that the whole usable screen is covered by outputs.)

Please note I typed this on my phone so there might be some mistakes or typos in there but you should be able to fix those. :-)

If you want a custom resolution that isn't in the list of your primary screen you need to create that first using cvt and then xrandr --newmode before anything else.

Hey thank you for mentionin that! I was down that lane too and also googled that solution with xrandr on Linux, but at least on Ubuntu 18.04 and 20.04 there is a problem with a nautilus, because it has huge glitches on an emulated xrandr as it is not running on that screen. Also you can't drag and drop windows to that screen as well, because window manager does not recognize it as a desktop. But mouse pointer can go there and I was actually able to share it with Deskreen and was able to see mouse pointer moving, but with huge glitches on background. This soulution turned out to be of no use.

That glitch result should only apply to the --fb variant. Using a disconnected output is not "emulating" anything, it's just overriding what's automatically detected and will not result in glitches. With intel GPUs, you can also add virtual outputs by fiddling with xorg.conf and use those, in case there are no spare outputs.

Yeah, this is what I meant by "X11-specific" solutions. Besides simply being an ugly hack (what if I don't have any spare outputs?), I'm not going to go back to XOrg just for that and a kernel-level solution sounds much more reliable anyway.

Kernel level sounds like the wrong approach to me. It might be more generic if done right, but having X11/Wayland support arbitrary virtual outputs directly seems much simpler and probably performs better. On X11 you can do this if you have an intel GPU by adding stuff to your xorg.conf. That makes it inconvenient and more of a hack than anything, but if this were to exist a layer above and you could simply add and remove them dynamically via xrandr it would be perfect. It had to be duplicated for Wayland though.

I'd normally agree, but seeing how long it took to get screensharing implemented "on Wayland" (the terminology gets weird there) and how much of a mess it is even now that it finally is (GNOME making up its own unnecessarily complicated system, KDE copying GNOME but badly and Weston doing something more reasonable but completely different and incompatible), I wouldn't hold my breath for a reliable implementation of virtual displays.

Any engineering going towards doing this on X11 is wasted at this point and waiting on the Wayland community to agree on and implement a common interface is going to take years, so a kernel-level solution seems like the only way to have this right now. FWIW, that is how SpaceDesk does it on Windows and their performance is great, so it's not like it's impossible to make it work.

I've actually already managed to get a kernel-level virtual display working, but haven't tested with Deskreen yet as it's 1am and I've been staring at C code for too long now. Might post it on HN if I end up actually packaging it up into something usable.

True, the situation currently is suboptimal. It feels like X11 was given up on while Wayland and its implementations and ecosystem aren't quite there yet.

I guess for Windows, a dummy driver is the only way to go since the layers above that are off limits for 3rd parties and it would be Microsoft who had to go ahead and do something there. But as you mentioned the wayland community is pretty chaotic with getting basic features implemented, so effectively it might be the same situation as with Windows ;-)

I'd be interested in seeing your finished product and trying out how it will handle different things you throw at it though.

Wow that is amazing progress you made! :D

I dreamed of people like you with deep knowledge of internals of operating systems will come together to solve the problem of virtual drivers! I mostly made Deskreen for that purpose. To bring a problem to community so we can make a really cool stuff that will outshine all the commercial applications out there and be the best screen sharing solution. That is a wonder of collective learning :)

It would be really great if you share a solution on Deskreen github.

Cheers

To be fair, I didn't write the kernel side of the implementation - that already existed and was made by DisplayLink, a company that Deskreen is actually in a way competing with.

I merely wrote a userspace utility that lets you make virtual screens without worrying about the low-level stuff like EDID and such. I'll definitely be posting something on GH once I've tested it more tho.

Sounds great!

Great thoughts !

Thank you for sharing what you know with us.