So far, everyone envisions convergence being about running applications found on your Librem 5 phone, on a PC monitor as a means to use your phone as a PC. But what about doing the exact opposite?
As we escape our respective Google and Apple eco-systems, our phones will increasingly be limited by the processing power found on the actual phone itself, instead of having either Google or Apple doing the heavy lifting for us when it comes to the processing power that we are used to seeing on our phones now. I anticipate these limitations to become very significant, the further away from Google and Apple, we go. Many people do not realize that their phone is often just the terminal that accesses large server farms to create the magic weāre used to seeing on our smart phones right now. The way I intend to get around these limitations, is to log in to my home Linux PC remotely from my Librem 5 and run some of the processor-intensive programs remotely. Of course, that means that my desktop PC programs will need to be displayed on my Librem 5. And thus we may need āreverse convergenceā. It seems logical that I may want some PC programs to format themselves to fit nicely on to the screen on my phone. Ideally, server/client programs would do that job. But most phone apps arenāt written to work as only clients/front-ends to a home server, although Purismās new app eco-system could theoretically gravitate in that direction. But as soon as my Librem 5 arrives in the mail, there are many familiar features that I will want right away. So the question is this. Is there any way to log in to my home PC which could be running PureOS, set my PC display back to my phone, and have the display and any applications running on it, automatically be formatted to fit my phone display? Will Libhandy and associated tools run on, and be available on a desktop x86 PC? I am guessing that Purismās app store for desktop PureOS might not make provisions for this by default. I would really like to be wrong about that. Does anyone here know how this issue is likely to manifest by default, and what Purismās plans are in this area? Any good ideas?
Since Google and Apple donāt want to encourage this type of consumer independence, I donāt know that anything like this exists in the market now. Perhaps at least for a while, the Librem 5 could make new features possible that donāt currently exist in the smart phone market now, using these methods. When I was fourteen years old in 1976, there was a guy I knew who could actually make phone calls from his mobile device (a two-meter band hand-held ham radio - old technology now). It wasnāt until over fifteen years later that we started seeing similar (brick) sized cell phones start to appear in the consumer market. Theoretically, the Librem 5 could similarly lead the way in to new consumer technologies, years or even decades ahead of everyone else.
Yes, in Linux the display is just another server (the X server). Even when using the display on the same Linux PC that the OS is installed to, this is how it works. You can also set the display of any Linux device that you log in to remotely, back to the device that you used to connect to it from. No special application is needed to do this. This ability to set the display of a device that youāve logged in to remotely, back to the device you logged in to from, is just a standard feature of all Linux distrobutions.
If I had my Librem 5 now I could easily remotely log in to my home Linux pc from my Librem 5 right now and run my programs from my Librem 5 remotely, unless for some reason, Purism were to disable that feature on the phone. But the question is about whether or not the X-server display running from your x86 PC could be formatted to look good on your phone. If youāve ever remotely logged in to a PC from an android phone using a remote display client app (there are several of them in the Android Play Store), youāll see your PC desktop all on your phone display. The desktop PC icons are all much smaller than a match head and you canāt read anything because it is all far far too small. You can use you fingers to zoom-in as you do with most apps in android. But then itās like looking through a keyhole at your desktop and/or applications. You can move the keyhole around in the same manner, using your fingers. It does work and you can use it that way to run any Linux program on your phone. But itās not at all practical.
This is why Phosh is being developed. This allows the same installed application to be used on either your phone or on your PC. I wouldnāt worry about Phosh-ing the whole Linux PC desktop and OS environment for now (if ever). But as long as the code is being written to run desktop applications on your phone display anyway, why not share that same code that is running on the Librem 5 phone, with the x86 version of PureOS (reverse convergence)? This seems like an ideal capability to add to the PureOS x86 version if Purism chooses to do it. I call it āreverse convergenceā (feel free to take ownership of that term though Purism). An added advantage would be that when developing apps on a PC that will run on your Librem 5 phone also, the app developers could change the server settings on the x86 PC to display on the PC, exactly as they will appear on the Librem 5. So there would be no need to load the app in to the phone to test it there while developing and testing the new app to run in both environments. You could even set your Librem 5 down next to your PC and see both screens (PC and L5) at the same time if you can find a way to run two instances of an X-server from the same PC at the same time. Regardless, it would seem relatively easy (for the experts) to tweak the x86 version of PureOS, to run the same display that we will see on the Librem 5, when coming from an x86 X-server.
This is likely going to be over-simplified, because Iām not knowledgeable about such things, butā¦
to my limited understanding, there are two things to worry about when using a phone screen versus a monitor screen: orientation (phones are by and large used in portrait mode, though they can rotate to landscape. This really isnāt an issue) and scaling (phones have pretty standard resolutions but on tiny screens). So it would seem that the x86 PC would somehow have to be able to know that the display its using needs to be scaled such that itās actually usable on a phone-sized screen.
Though if PureOS on a L15 and PureOS on a L5 are the same operating system, then the functionality is already there, isnāt it?
Minor? technical note: In your proposed use-case, the X server would be running on the phone (Xwayland), not on the desktop. Itās the X-client-library running on the desktop.
As for it getting proper scalingā¦ I donāt know if Xwayland properly pulls the DPI from the wayland compositor or not, Xorg just assigns it to 80dpi (you can manually override this). In theory, if the desktop applications use libhandy, when they connect to a tiny Xwayland screen, they should auto configure for high DPI mode.
I think you are correct about the phone orientation (portrait vs landscape view) issues. I donāt know if a remote X-server could adjust accordingly or not or if the view orientation could be a function of the phone. This is a good point. But either way, the app would go from being inaccessible for remote use to becoming accessible remotely with at least a fixed orientation.
But when it comes to the scaling and use of Phosh on x86 applications, it would be standard to add a switch or using a new variation to an existing switch setting in the command line that connects the X-server to the client machine (in this case the Librem 5). Somewhere in the command-line display settings that call up the display on to the remote machine, there might (for example) be a /P switch to specify enabling phosh features.
When it comes to whether or not the Phosh feature should already exist in the x86 version of PureOS or not, that is a good question too. It depends on what the owners of PureOS at Purism had in mind when they released the x86 version of PureOS. I would have left the Phosh code out in the x86 version before compiling, since it could appear to be useless and might break something else. Since the x86 version was created before the L5 came along, maybe they didnāt see a need to add it to the x86 version. Sometimes code that was written to run under an ARM architecture may nor run automatically when compiled in to run in an x86 architecture, without some tweaks. But maybe supporting Phosh in x86 was the plan all along for just this purpose.
It has been probably fifteen years or so, since I actually did an ārloginā followed by an āxhostā to use a Linux desktop remotely. I always believed that the X-server came from the server machine since the ārloginā command had to come first before the display could be set up using āxhostā. Things have probably changed significantly since then. Is it standard now to not use the server machineās X-server at the client machine? I know that the ārloginā followed by āxhostā are probably an old method by now. But while setting up the āxhostā connection, if you used the wrong display resolution, refresh rates, or other critical display settings in your command line, the display either looked bad or not at all. You had to know what the settings need to be to match your given monitor and had to specify them. You could set the whole login and display setup in a script and then just call the script to login remotely. So I figured that it might be easy to set up a shortcut on your L5 to log in to your home PC remotely, set the display back, and then execute your given program. But the question is whether or not Phosh can be made to work under those conditions.
Hm, I canāt speak to how it worked 15 years ago from personal experience. I would be surprised if the Xserver was running on the remote machine even then (given that the Xserver needs access to scanout the display). That said, the X server can act as an X client too, so Iād guess what you were doing was telling the remote machineās X server to do its own compositing, then send the output as a single frame to the connecting machineās own X server for display. This is similar to how x11vnc works, only it sends the X serverās output via VNC instead of raw X11. For individual remote applications, you can also use SSH X11 forwarding, it works pretty well if your network can keep up (itās latency sensitive, and X11 is actually pretty terrible as a network transport layer).
A lot of the distros now include Phosh (Debian, Arch, Manjaro, Fedora and openSUSE), so you can install Phosh on your server and use VNC Wayland to connect from the Librem 5 to the remote desktop on your server.
It does seem like it would function better if the x86 computer were to do all the āreverse convergenceā (divergenceā¦?) work in this threadās scenario, since it will have both more resources and more power.
Iām still amazed by the dependency on visual output. Remember in the old movies the computer would click, buzz, and whirr, and the only output was a ticket that said: āYou answer is: ______.ā ?
(42)
Maybe all you need is an icon that says āYouāre program is running ā¦ā. āhas abendedā, āhas abortedā, or āTILTā.
Iām also reminded of the old SETI program that would use your unused computer cycles remotely.