Linux version

[Hekel1989]

Hi, any chance you've got a Linux version in the works? Thanks :)

[Wektory]

Hey, I'm joining, a Linux version would be great.

[JPersson77]

Seems like a big undertaking but I will consider

[Hekel1989]

Seems like a big undertaking but I will consider

If you need any help on the Linux side, let me know, and I'll research it, test it, etc.

I'd volunteer to help coding, but my C is non existent

[JPersson77]

Thanks mate for wanting to help out, I'll keep it in mind

[KucharczykL]

This would be amazing :pray:

[cali-95]

If you only need a simple version of LGTVCompanion without a UI, then checkout my project: https://github.com/cali-95/LGTVLinuxCompanion

[JPersson77]

Oh cool 😀

[TCX0Lt0X]

neato

[Zepticon]

I would also love a Linux version <3

[CaptaiNiveau]

What exactly needs to be done for a Linux version? Mostly a UI rewrite I guess, are there other parts that might not be portable?

Do you have a preference for a UI framework for the port?

[JPersson77]

An UI rewrite indeed. I'm no expert here so I cannot say what would be the better choice.

What might require additional thinking though is how to deal with some specifics of win32. Again I don't know Linux. Portability was not part of the design, but the foillowing executables have their own project in the github codebase.

• The windows service is used as backend. The service is started before the logon prompt, and ensure that the TV will power on before the logon screen / as soon as possible. The service read a JSON file for its configuration. Regarding win32 specifics the service listen to windows power messages (screen on/off/resume/shutdown etc). So a linux port needs the equivalent. The service also manages the logic for communicating with the TVs
• The main UI is used for configuration of attached devices. Saves the config into a JSON container. It can also accept command line input which it rely to the service using named pipes as a means of intra process communication. This is probably relatively straigthforward to port
• The daemon is launched after a user has logged in and reside in user space and provides functionality that cannot exist in a service. Reads the JSON file for configuration. Performs primarily User idle mode detection and Monitor topology changes. Communicates this to the service via IPC.
• The CLI is a console application which accept user input via command line, communicate with the devices, and print the output to STDOUT. Reads the JSON file for device configuration but is self-contained and does not rely on the service to communicate with devices

I'm happy to help with understanding the code and thinking. Without knowing the specifics of Linux I think it would make sense to start by replicating the basic functionality of the service by investigating how Linux deals with setting up a service and how to be able to listen to relevant power events in the service. Once that is nailed it should be relatively straightforward to copy the logic from lgtv companion to send power on/off commands to the TV. THis also includes determining include libraries for dealing with json and network communication.

Edit: another peculiarity of windows is that there is no easy way to determine whether the system is shutting down or rebooting. So in the service there is a callback where I'm catching a specific event (1074) in the event log for this. This might be more straightforward on linux

[CaptaiNiveau]

Cool, thank you.

I read up on this: There's different service managers, like systemd, runit and a few more. To be agnostic to them, you have to have some simple start/stop/etc. scripts (or a binary you call with the respective argument), to which you point in a service description file. These are specific to the service managers and are activated by the user (or the package on installation), for example sudo systemctl enable lgtvcompanion.service && sudo systemctl start lgtvcompanion.service.

For power events, that also differs based on the init system. systemd is widespread and both a service manager and init system, therefore creating configurations for that should be enough for most users. However, I'd like to keep this agnostic to the init system. Just calling a binary with the respective power event (e.g. lgtvctl shutdown) should be good enough to be used in the different config files, just like the service managers.

Which Framework did you use to create the UI? I'm not that deep in the C++ world, but I do want to get into it.

[JPersson77]

All UI is native win32. If you open the solution in msvc you can see the dialogs as resources and inspect what components was used. A basic message loop is then implemented to manage the windows messages.

On windows there is the service manager (SCM) which seem very similar high level to what you describe. You can check the methods used for installing, deinstalling, launching etc at the very top in service.cpp

Yes there many ways to go about structuring a new project. Having a separate binary for controlling the TV might be a good idea. The implementation of the CLI was added much later for the lgtv companion app, but if I had started with that then maybe I would have built in that direction. You will however find that the equivalent of that binary is pretty much the C++ CSession object (session.cpp). There is one session object per configured device and it is responsible for all comms with the device. In turn the sessions are managed by CSessionManager (also defined in session.cpp)

[CaptaiNiveau]

Do you think a rewrite in QT would be a good idea? That way it could theoretically fully replace the windows only UI and it'd be less code to maintain than two different GUIs. Bonus is that it might work on Mac as well.

[JPersson77]

Oh that is a tough one.

I mean, I see niceness in making the app portable and I think QT can look adequately good. But I'm probably not going to be able to develop on my own due to general lack of time. Then again, the UI is very separate from the service etc and a reason to work with github is so that others can work on viable solutions which can more or less be dropped in. Maybe it won't be too complicated of a switch. I'm pretty confident it's doable, at least when it comes to the UI.

A design goal has been to just make it work and avoid downloading external runtimes. Hence why all libraries are statically linked in the current binaries. Not sure if that can be achieved with QT but something to consider.

So, potentially it could be a good idea. But if we are talking about making the current codebase portable then I think it's probably a good idea to branch

[CaptaiNiveau]

Yeah of course. The rewrite needs feature parity to replace the old one. I'll look into it.

Just out of curiosity, what do you think of Avalonia? I have some experience with WPF, Avalonia is its successor in a way. It's cross platform and way better/faster at rendering than WPF thanks to Skia.

[JPersson77]

Just from the outset I think Avalonia is more interesting than QT

[CaptaiNiveau]

Realistically Avalonia is a lot more doable for me, as I have way more experience with C# than any other language. I do want to learn C++ specifically, but not necessarily this time. Avalonia definitely has the potential to look better than QT from what I know, but GTK would probably also be a good candidate.

[CaptaiNiveau]

I might try to start with a UI rewrite in Avalonia then. There's a lot of nice resources for Avalonia online, tell me if you like a specific UI theme or something else.

[JPersson77]

Sounds cool! I like an uncluttered and responsive UI. Material design / winui3 style is great IMO.

Happy to discuss this further. There is a discord as well

[KeyofBlueS]

Nothing to add here, I would like to just join the chorus of those who would like the application also for Linux! At least the CLI!

Thanks and best regards.

[CaptaiNiveau]

I'm trying to port the project to CMake, so that I can build the platform independent parts like the CLI on Linux.

In the meantime you (@KeyofBlueS) could check out either bscpylgtv or LGWebOSRemote, as they already provide a CLI. I've been using those in the meantime until I get to a decent point with this project, trying to integrate into my pc using systemd services at boot/shutdown/sleep (sleep triggers for all hibernate/suspend/etc. combinations).

I'm kind of tempted to just rewrite the LG CLI in C#, too, but I'm not sure if I really want to get into that. May be easier to just have one C# library that I can call both from the GUI as well as the CLI app, but it'd probably also be possible to integrate the current C++ code that way.

[KeyofBlueS]

Thank you for your response @CaptaiNiveau. I had been using those tools, but after a recent upgrade to my TV, they stopped working. It seems that the new firmware rejects non-SSL WebSocket connections. Unfortunately, bscpylgtv doesn't currently support SSL, and while LGWebOSRemote appears to have added SSL support, I've been unable to make it work (encountering an 'Error: Argument lengths do not match' message). Additionally, it seems that neither tool is well-maintained at the moment.

[CaptaiNiveau]

Ah fair. I rooted my TV and blocked all updates, seems like that was a good idea. Does this repo deal with that successfully? I won't update my TV to try that though, as it might break my root, too.

[JPersson77]

Yep the SSL connection method is supported by default on all newer builds