Showing posts with label LXQt/LXDE/Lubuntu. Show all posts
Showing posts with label LXQt/LXDE/Lubuntu. Show all posts

Tuesday, 7 July 2020

Reinstall KDE system with LXQt [3]

This is the third article in a series about problems with KDE leading to a reinstallation with LXQt. Both running on top of Debian 10.

The computer concerned is running two NICs because it needs to access both networks that I have here. I have the main one based on a corporate wireless link from next door, which is filtered and throttled, and a second networtk based on a Skinny cellular broadband network modem, which is not filtered or throttled, although speed is moot since there are limitations inherent with 4G cellular data. The Skinny modem is connected to the local devices through a Ubiquiti AirRouter, which includes a DHCP server and network switch. It also provides the wireless network for phones or tablets. The capabilities of the AirRouter are much better than those built into the Huawei Skinny modem for internal networks and that is why I am using it.

There are some issues with LXQt mainly in panels but apart from that the reinstallation of software has gone well on the platform. One issue with this computer in general is that it needs more installed RAM and I am planning to address that in the next week or two, since I need it to be able to run a virtual machine at the same time as the range of stuff I normally use it for. One issue was reinstalling Gimp, I had difficulty in working out where Gimp keeps its config data as I wanted to copy over the config from my existing computer. It turns out that Gimp uses ~/.config/Gimp as a path, but apparently it also used a Flatpak specific path in ~/.var/ to store some data and there is considerable confusion over why it maintains these two paths especially as the user interface of the Preferences dialog doesn't actually point to the ~/.config path when it appears it should.

One of the interesting experiments this week has been to work with the mounting arms that I use to hold some displays. I have used Brateck wall mount arms with VESA adapters on them for this for some years. The key has been to modify these to allow fine control of the height so that when displays are stacked vertically, it is easy to put them close together. 

This photo shows how the attachment of the arm to the "wall" (in this case a vertical post attached to the desk) has been modified to allow its height to be adjustable. This is done with two right angle brackets which are bolted together using 80 mm length M6 gutter bolts, which gives theoretically an adjustment range of 80 mm.

I have to work around issues with the backup system from one of my computers at the moment. rynsc has not been able to connect over the network between the computers and running the backup locally on a computer seems to be the way to go at the moment.

Wednesday, 1 July 2020

Reinstall KDE system with LXQt [2]; KDE network and display configuration extremely difficult with numerous bugs

As related yesterday I found various issues with KDE on a computer and decided to reinstall Debian 10 with LXQt as the user interface. After completing the installation I attempted to use ConnMan, which is the network configuration manager that comes with LXQt on Debian, to do a manual configuration of the 1.x network adapter to set its IP address manually without using DHCP. However, my experience has repeated that found in another computer where I had used ConnMan in the past, where it has continued to send DHCP requests for this network adapter despite the manual setting and overridden the blank "gateway" setting specified in the manual settings, with the DHCP settings. In this case, the setting that was overridden was the DNS server; it was configuring the system to use the 1.x network's DNS server address obtained via DHCP instead of the 4.x network's DNS server obtained via DHCP for the 4.x network adapter. 

As I have noted the Lubuntu network configuration manager does not have this problem and is definitely the best out of all three. However as I am not sure at this stage of being able to install this on the computer, my next step was to uninstall ConnMan and set the network parameters in the /etc/network/interfaces file. After uninstalling ConnMan, dhclient could not complete any DHCP requests for any interfaces; it seems that dhclient is configured to use settings provided by ConnMan and would have to be reconfigured to work with it. 

The interfaces file entries ended up looking similar to this

auto enp0s31f6
allow-hotplug enp0s31f6
iface enp0s31f6 inet static
           address 192.168.4.173/24
           gateway 192.168.4.11
auto enx00500b60c1eb7
allow-hotplug enx00500b60c1eb7
iface enx00500b60c1eb7 inet static
           address 192.168.1.173/24

In addition, /etc/resolv.conf contains the entry
nameserver 192.168.4.11

After completing these entries the system was rebooted and further checking confirmed the settings had been applied. In addition it was confirmed there had been no further lease requests to any DHCP servers, the lease for the 1.x network adapter (the problematic one that was pushing through unwanted default gateway and DNS server settings) had expired and had not been renewed. 

It therefore appears I have resolved so far the display issues and also the network issues. The only remaining issue out of 3 mentioned in the original article to be resolved is to get x11vnc running. Then there are the separate matters of reinstalling the software that was on this computer before I reinstalled it.

LXQt has some obvious differences from KDE and one of those is the panel configuration is different and at present it will not support more than one panel on the desktop and will not support a panel being in the top position on the lower display, which in the configuration I have with my displays is the ideal place to have just one panel that is shared between both screens. Although a panel can be placed there and used normally, the panel cannot be right clicked and configured using any of the usual menu options for configuration because the menu is truncated. The only fix being to move the panel to the bottom using the panel.conf file, stop and restart the panel and then configure at the bottom then move back to the top when finished configuring. I will have to check with the LXQt project to see if they have any fixes for this problem.

The other key issue of course is fewer widgets available yet for LXQt. The main one I do not have is the disk free space. I can simulate the CPU monitor bars like I am using on KDE (they show CPU usage, memory usage and swap usage) with some of the built in widgets. So apart from some niggling issues related to the differences between the desktop environments I expect to proceed quickly to having this system up and running again fairly soon and to be able to have a more reliable and easier to use system than I was experiencing with KDE.

Tuesday, 30 June 2020

Reinstall KDE system with LXQt [1]; KDE network and display configuration extremely difficult with numerous bugs

KDE has some great reputation as a desktop environment in Linux and has won considerable plaudits. It however has numerous unresolved bugs which I have observed in the display and network configurations that are leading me to ditch KDE on one of my desktop computers in favour of LXQt. I have had three computers running KDE and one running LXQt all on top of Debian but I will be taking two computers onto LXQt and therefore only having two running KDE.

The concerning issues that are being observed with KDE mainly concern non standard configurations in both display and network, and also the inability to use x11vnc on KDE which somehow blocks it from running. The problem can be summed up as KDE not being sufficiently versatile to allow different configurations where the standard ones are insufficient. For example the VNC client designed for KDE, Krfb, will only buffer one display on a two display computer, making it inferior compared to x11vnc.

The summary of the issues experienced to date is:
  • Networking. Unable to configure a static IP address and route for a network adapter and stop the automatic configuration of an adapter via DHCP. Unable to disable a network adapter and stop it from connecting as KDE ignores the disable setting and creates another new adapter with the same settings as the disabled one (the only option then is to disable or remove the adapter at hardware level).
  • Display. Unable to save the configuration of two displays on my computer. The displays are stacked vertically. KDE is unable to remember these settings and after each reboot, defaults to side by side displays.
  • Remote Frame Buffer. As mentioned above, KDE stops x11vnc from working. Krfb will only buffer one display in a dual display system.
My networking requirement is special as the computer has two network adapters due to being required to connect with two different networks. On LXQt this is relatively easy to set up. On KDE I have experienced the problems mentioned that it keeps ignoring the manual settings. Only one of the adapters can be a default gateway because there can only be one default route to the internet. I have made it clear that the manually configured adapter will not have a default gateway but KDE ignores the instruction to use the manual settings and keeps sending DHCP requests on that network. The net result is it has become impossible to enforce the required network configuration of the computer. 

To illustrate that this is not difficult on other desktop environments, I have set up a virtual machine on the same computer which is set up in VirtualBox settings with the two network adapters with the appropriate configuration in LXQt (the VM is running Lubuntu). This has worked flawlessly without all the dramas that KDE is creating. The network configuration on LXQt on the virtual machine is implemented as the option "Shared to other computers" which allows the specification of an IP address and netmask without gateway settings. In other words that adapter does not have a gateway specified and must not send DHCP requests on the network.

Another difference between LXQt and KDE with regard to networking is the list of configuration methods and their implementation. In the connection manager that is provided with Lubuntu, which is admittedly different from LXQt on Debian, "Shared to other computers" lets a manual IP address and netmask be specified. But this information can't be put in when selecting the same configuration method in KDE. The KDE network manager in this case automatically creates its own IP address on the 10.x.x.x network and you obviously have to configure the rest of your network to match.

The key problem with KDE is it takes over too many things in a computer and makes it difficult to work around its default settings. In LXQt it is extremely straightforward to configure a non standard dual display and save the settings in a config file, extremely straightforward to install and manage x11vnc and it can be more straightforward to configure a network adapter. However ConnMan is a bit more tricky to configure than the Lubuntu network manager - the Lubuntu one is one of the best ones I have used on Linux overall.

I have started a complete reinstall of Debian 10 on the computer despite my misgivings over having to reinstall all the software (including the tricky iscan software for the Epson scanner), because KDE has such an impact on the system, that it is difficult just to put LXQt over the top of it.

Thursday, 28 May 2020

HOWTO: Set laptop screen brightness in Lubuntu

Some laptops have function keys that can be used to adjust screen brightness. These may not be supported on all laptops, however. In that case, there may be the controls in monitor settings or power management to adjust the brightness.

In my case I wasn't able to find anything, so I discovered how to adjust this using a command line setting. Install the xbacklight package and then invoke it with a command like this

xbacklight

By itself, this will give you the current reading.

xbacklight -set <x>

Pass some number after the -set parameter and it will set the brightness. I found 50 to be a good number after discovering the default is just 12.5.

Thursday, 21 May 2020

Ubuntu LTS vs non LTS releases

Good day. As I install various versions of Ubuntu on a few virtual machines and computers and also use Debian on some as well, there is naturally an important comparison to be made between the Debian and Ubuntu release cycles. Ubuntu has stabilised on a twice yearly release cycle but the LTS releases are every two years and as I am now finding, the 5 years of support for an LTS release is much preferable to only a few months for intermediate releases. Recently I have had to deal with systems installed with Disco releases that are now not being supported for updates as what I understood to be about two years of support has been dropped to just nine months resulting in 404 errors when apt attempts to contact the servers for updates. This in turn affects the ability to install new software as well as update existing packages.

This realisation leads me to conclude that as far as any version of Ubuntu is concerned, it is best to stick with LTS unless you are intending to keep updating every year or twice a year to the latest release. For my laptop that is only used occasionally I am depending on it being able to be installed with new software at any time and not have the situation I had this week where I was unable to install Zoom because the supporting packages for the installation were not available from the official repositories. I was then forced to update to a later version before being able to complete the installation.

For this type of situation we must therefore conclude that it is best to rely on the Ubuntu LTSs which like Debian come out less frequently but are supported for a longer period. The latest LTS is 20.04 (Focal) and hopefully it won't need to be updated until at least 2 years when the next LTS comes out for the software I use on the laptop because I don't want to be caught the same way again. The best thing that can be said is that you can streamline a reinstall by remounting /home to a separate partition and then install as much software as you can to your home folders but this is not possible to achieve for software that relies on apt, dpkg or snap to install. I have only been able to achieve this with portable type software such as AppImage that can be placed into any path as a single file and run there, as well as Firefox Developer and Thunderbird which are designed as portable applications that can run from any folder path and consist of multiple files and folders that can be extracted to any path from an archive.

Tuesday, 31 March 2020

Stopping desktop notification popups on LXQt

I see a fair bit of LXQt, whether it is on my one desktop that is running it on top of a Debian install, or my preference for laptops and virtual machines which is to install Lubuntu for fast pain-free installations, especially with non-free firmware and low resource use. Debian remains my preference for my desktops due to its versatility and feature set being more oriented to hard core geeks like me. Hence the one desktop that is running Debian/LXQt rather than Lubuntu, which is annoying in having disabled hibernation, among other things.

One thing that itself is a nuisance on a computer for screen recording is the popup desktop notifications in LXQt, which for example take over the browser message popups, or the on screen feedback to up and down volume buttons being pressed on the keyboard, and as far as I can tell, always appear on screen 1. There is only one way to get rid of these, but you can't configure them by application as you can on some desktop environments. Nor is there much control over them in the LXQt config center. So it is just easier to turn them off altogether.

Just go to LXQt configuration center, open Session Settings then on the first screen "Basic Settings" in the "LXQt Modules" window, find "Notification Daemon" and stop it, then untick its entry as well.

You will still have to look at browser notifications - I recommend turning them completely off as well.

Monday, 18 November 2019

Change Monitor Configurations Permanently in LXQt for Screen Recording

As we have discussed in the past, I use LXQt in two different configurations with my various computers. Lubuntu, which now uses LXQt as its desktop environment, is what most of my non-desktop computers use. For example a media playback computer and a laptop are normally set up with Lubuntu which is quick and easy to install as it has all the drivers included in the setup.

For my desktops I am using Debian, with LXQt on one computer in particular because this computer needs stuff like hibernation that is better supported in Debian, but also with LXQt it gets around some of the bugs in KDE which I use on other desktops, as well as ensuring the resources that KDE uses aren't wasted in its lower spec. So I am testing these settings on that desktop because it has two screens and it is in fact the main computer that I have at the moment that these settings are important for.

Because I use this computer to do screen recording (using SimpleScreenRecorder), the screens have to be nearly at diagonal placement to each other. That is, the left hand screen and the right hand screen are to the left and right of each other, but in a vertical sense there is only a tiny overlap at the top right corner of the left screen and the bottom left corner of the right screen. This means the mouse can only be moved from one screen to the other by passing through a very small area of overlap that is in the top right corner of the left screen and the bottom left corner of the right screen, and also windows needing to be dragged from one screen to the other can be passed through this small area.

The reason for this configuration is that for screen recording, we have the software that is doing the recording running on the left (control) screen, recording the right (target) screen. We want to ensure what we need to do on the left screen does not cause anything unwanted to be displayed on the right screen. Some examples of this are:
  • accidentally moving the mouse from the control screen onto the target screen
  • any action on the control screen which causes pop up notifications, such as operating keyboard volume up and down. Even if the popup is on the control screen, if it is adjacent to an area of the target screen it can cause unwanted display of information on the target screen.
We ensure this by making sure as described above, minimum overlap between the two screens, just enough to get the mouse from one to the other and drag windows from one to the other. We still have to be careful not to run the control screen applications maximised to ensure the mouse is kept out of the top right corner of the control screen at all times other than actually going from one screen to the other.

The LXQt monitor settings GUI doesn't actually position the screens exactly as we would like to. They can be aligned vertically and horizontally close to the suggested outcome, but with a small amount of unwanted superimposition of the two screens. Fortunately you aren't limited to using that GUI to set positions. After changing the positions in the GUI and closing applying or saving settings, you can further tweak these with manual editing in the file ~/.config/lxqt/lxqt-config-monitor.conf. These seem to be just the same sort of parameter specs as running xrandr will spit out for you. Under the [currentConfig] section are the ones presently being used for the computer and with a few adjustments we can eliminate that superimposition and ensure the overlap is as small as possible. For example, with the control screen being screen 1 on HDMI-1 (settings\1) at a resolution of 1440x900, xPos=0 yPos=745 are the settings and for the target screen being screen 2 on HDMI-2 (settings\2) resolution 1360x768, xPos=1440 ypos=0. 

The names of the displays xrandr generates for this system are interesting as it has one HDMI port, one DVI port and one VGA port, yet the DVI port appears as an HDMI port in the list of outputs. It seems this initial configuration of the displays happens just after logon. Also, the settings are saved in the user's profile (~/.config folder) which means when reinstalling, these settings should be reused into the new installation of LXQt.


Tuesday, 15 October 2019

How to create a desktop menu entry manually in Linux

This is kind of an odd thing to be posting about nowadays with Linux desktops mostly including a menu editor or installable third party packages like menulibre and alacarte being able to achieve the same outcome. However, LXQt does not include a menu editor that is comparable to the above options, and whilst both of the above can be installed in Lubuntu or Debian/LXQt, the results of running them are confusing. It is possible with PCManFM-Qt file manager to edit applications shortcuts directly in a specific area of the standard user interface but that is confusing and difficult to understand. Fortunately the majority of desktop environments support a standard method of creating shortcuts as .desktop files stored in a standard location.

The .desktop files are created in either of the following locations: /usr/share/applications or ~/.local/share/applications. The difference between these is that the former location is computer based and the latter is user based. For this example we have downloaded Firefox Developer and extracted it from the download file. This does not give us that menu shortcut so we have to create it. Typically we will copy the FFDE files to ~/Applications folder and create a local shortcut in ~/.local/share/applications which has a double advantage at reinstallation time that both the application and its shortcut are located in the user profile and therefore do not need to be reinstalled when the operating system is.

The typical format of the .desktop file looks like the following (in this case the actual parameters used to start Firefox Developer from where we installed it):

[Desktop Entry]
Categories=Internet
Comment=Firefox Aurora with Developer tools
Exec=/home/patrick/Applications/firefox-dev/firefox %u
Icon=/home/patrick/Applications/firefox-dev/browser/chrome/icons/default/default128.png
Name=Firefox Developer Edition
NoDisplay=false
StartupNotify=true
Terminal=0
TerminalOptions=
Type=Application
Version=1.0
 
Some of the above might not be needed.

The key issue, however, is that LXQt (at least on Lubuntu, but probably also on Debian) does not seem to recognise user specific icons as part of its menu. When one was created like the above, it ended up being put into the Other submenu rather than the Internet submenu. Likewise one could be created with menulibre and would be created in the same location by default (~/.local/share/applications) but ran into the same issue that LXQt would push it into the Other section of the menu. I am still experimenting to see how this can be overcome but for now, either method is possible but if both are creating the same outcome then using menulibre is obviously preferred as a GUI.

Friday, 20 September 2019

How to PERMANENTLY disable an input device in Linux (Xorg Display Server)

About 2 months ago I posted on how to use the xinput command (on Ubuntu and derivatives) to disable an input device. This, however, only works until the next time the computer is restarted. In addition, not all distros provide the xinput command; Debian doesn't, and I haven't done any research to determine whether this command needs to be installed or if there is a Debian specific alternative. For the time being, the device in which I need this function to work is my Dell E6410 laptop with an Alps pointing stick which is drifting. By default this is enabled alongside the touchpad, so you can use either of these devices, but there is no simple way to disable the touch stick, even if you plug in a USB mouse as I often do.

The answer for when the Xorg display server is used (generally this is the default display server based on X11 for many years, that is now gradually being superseded by Wayland) is to change the configuration settings in a file that is stored in /usr/share/X11/xorg.conf.d/ and in this case the file name to be edited is 40-libinput.conf . In order to effect the disablement, the xinput list command was first used to get the name of the touchpad device, and then this section making use of that name was added to the bottom of the aforementioned file:
Section "InputClass"
        Identifier "disable touch stick"
        MatchProduct "AlpsPS/2 ALPS DualPoint Stick"
        Option "ignore" "on"
EndSection

So that section in the file is pretty straightforward. The MatchProduct entry contains the exact device name string that we got from xinput list and the Option specified "ignore" "on" tells the Xorg server to ignore the device and not enable it.

After doing a reboot the touch stick was found to be out of operation and the xinput list command no longer lists this device.

As I noted in my previous post, the flaky touch stick on this laptop has been a significant issue since it will cause the mouse pointer to drift across the screen quite randomly even when an external mouse is in use and possible options to disable the touch stick at a hardware level (there is for example a Bios setting that in theory would disable it with an external mouse connected) have not worked so far. I did not investigate any possibility however of physically disconnecting the device inside the laptop, but I believe this could be quite difficult as the touch stick is physically located between the keyboard keys and thus it is probably at a hardware level integrated into the keyboard itself and therefore could not be unplugged.

Having this option to disable the touch stick is proving extremely useful since the laptop is otherwise in very good condition for its age and with the installation lately of a 160 GB SSD in place of the regular hard drive and the replacement a few years ago of the original battery, with the limited amount of use since then meaning the new battery should still have at least 90% of its life left, if carefully looked after it will keep going for another decade probably.

I am guessing this xorg.conf.d file entry will work with most distros (including Debian) even if xinput command doesn't work on some.

Friday, 26 July 2019

How to disable an input device in Lubuntu

I have a Dell Latitude E6410 laptop and it has one of those stick pointing devices built into the keyboard. They are just a little joystick that you can use to move the mouse except it is just a tiny little thing that fits between keys and is actually quite hard to use.

Anyway this week the stick thing started pushing the mouse to the top right hand corner all of the time. So I have looked up how to disable it from being in operation, since it was doing this with everything, even in the BIOS or the Linux installer.

So the command to use for (L)ubuntu is xinput so the first thing is to use its list parameter to get a list of devices. Each device will have an id number next to it, in this case 18.

Then the next thing is simply type in xinput disable 18 and that disables the device. Which means using the touchpad and an external USB mouse just got a whole lot easier. I'm not sure there is any hardware way like a key sequence you could press that would achieve this, so this was a great outcome, as I doubt there was anything else I could have done, although I was able to use the stick to move the mouse around. Without being able to resolve that the laptop would have been nearly unusable, which would be a concern as it is otherwise in extremely good condition.

Sunday, 21 July 2019

Lubuntu vs Debian / LXQt

As we well know my preference is very much the use of Debian rather than Ubuntu. I do this because Debian better supports experienced Linux users like me. Debian however omits firmware drivers for non-free hardware by default which means a lot of fiddling to download and install and there are some other capabilities like mtp and sudo that need extra work to configure. On the other hand Debian supports hibernation by default.

On some devices such as a laptop the easy installation of Lubuntu is more preferable if hibernation is not needed for example. Lubuntu also has sensible default settings for pulseaudio, specifically flat-volumes=no, which the Debian community has still not been able to address (debian is one of the very few distros that does not implement this by default)

Debian with LXQt will remain the choice for the computer at my desk that is used to play my worship music and video collection because this computer also gets used for day to day stuff and hibernation is a huge benefit. However Lubuntu will be my OS of choice for computers like a laptop or NUC that have wireless hardware in them.

Thursday, 9 May 2019

Lubuntu 19.04 with LXQt

It should generally be known by now that the Lubuntu project, which produces a version of Ubuntu that utilises the LX desktop environment for low resource usage, has switched from LXDE to LXQt in its more recent releases. The use of LXQt provides for a refreshing modern interface design in this application and for me, it makes it possible to consider LXQt based distros as being a worthwhile replacement for XFCE, which is falling too far behind in development.

Although these days I prefer to use Debian as my base distro and install one of the desktop environments provided by the installer (KDE, XFCE and LXQt are all available in Debian 10, along with several other environments), for some of my computers extra hardware drivers such as for Wifi simply make it more convenient to install a Ubuntu-based distro that has these drivers built in. An example would be the NUC and the R500 laptop. 

The Lubuntu installer is very straightforward with a smooth GUI that breaks down the installation steps into a small number and it installs very quickly from the DVD ISO image on a pen drive.

The best part is that it works flawlessly compared to my experience of missing GUI interface tools for network connections in Debian 10/LXQt. The connection manager supplied in Lubuntu is interesting in that it uses a text based interface to set the parameters, but everything worked exactly as it should have for the requirement of a wired connection only working on the local network and a wireless connection for Internet. It would seem in the Debian installation I may have had two connection managers conflicting with each other but this is difficult as there was not any installed by default and I had to find which packages to install.

I will be using Lubuntu more in future on the wireless devices that I only use occasionally and on VMs where I need to test against a Ubuntu based distro so that I don't need to use up too much resources in the host system. LXQt while still at version number 0.1x has had a fair bit of updating lately since the earlier version that I installed over XFCE on systems for testing and then ended up discarding because of too many missing features so it is good to see this progressing and becoming more user friendly.

Tuesday, 30 April 2019

Networking / Wireless with Debian LXQt

There are some issues possible with LXQt if you have Wifi because of limitations in the current Buster install. Some of these may be resolved by the time Buster is released...but not all, for reasons explained below.

First issue for Wifi is if the drivers are non-free, as is fairly likely. You'll notice this at setup if you get asked for a driver file to allow the wireless networking connection to be accessed (more likely if using the network based installation). This occurs because Debian is configured by default to have non-free stuff in separate repositories and access to those has to be specifically enabled in the sources.list file. Basically you have to change the first set of repository statements in the file that point to main, to point to main contrib non-free. This is due to the Debian licensing model and philosophy.

After that you can, for example, install firmware-iwlwifi which is the package for Intel wireless. 

The next issue is that there is no network connection manager installed by default in LXQt with Buster. Installing network-manager-gnome is the way to get this, along with nm-applet. Then you have to edit /etc/NetworkManager/NetworkManager.conf and change the following:

[ifupdown]
managed=false
 
change the false into true. This is necessary to ensure that you can manage the wired interface as by default you will not be able to manage this.

After that you should be able to get the wireless interface working on your computer. If you don't have wireless, having Network Manager installed is still useful if you need to set up anything non default with the wired networking such as a static IP address. 

UPDATE: I had a lot of trouble on this computer getting Network Manager to be able to set the IP address and parameters for the Ethernet cable port properly. The settings in the /etc/network/interfaces file read

iface enp3s0 inet dhcp

whereas in Network Manager I had changed to manual configuration which should have been shown in the file. So there is an ability to directly edit the parameters in that file so in our case we write something like

iface enp3s0 inet static
    address 192.168.1.222
    netmask 255.255.255.0

with no gateway or DNS servers or anything because this particular interface is only being used on the intranet and not to access the internet. But the question remains why Network Manager is not setting those parameters in the file. In other words it seems Network Manager was only able to configure the current session when it was used and not the configuration settings for next time. Network Manager was apparently able to handle the wireless connection. Possibly the issue of what is being managed in the Network Manager settings mentioned above.
 


Saturday, 23 March 2019

Webcam with Linux [1]

We need to do some livestreaming on Facebook Live for a project I am working on. Using a phone is quick and convenient, but pretty limited unless it is a selfie. So the next option is a webcam connected to a laptop and remotely located from it by a 5 metre cable which lets me put the camera just where I want. It also gives me the option of bringing in sound from another source and mixing it into the livestream.

I will be streaming to a secret Facebook group in order to test the ability of the webcam and computer combination. The computer is running Debian Buster and LXQt and will use the Google Chrome browser to run the livestream session.

So watch this space as I will report back. Currently the webcam is a Microsoft Lifecam which I happen to have lying around, but I am planning to get a Logitech C270 and do some testing with it in a couple of weeks. Right now I am hoping to test the Lifecam at the site tomorrow if I can get my act together and finish installing the laptop as well as making a pole and clamp to be able to raise the Lifecam up high for a good view. The third thing is to see if I can come up with some sort of microphone to pick up the sound as this webcam doesn't have a mic of its own.

I hope to start writing part 2 later tonight when I have finished testing with my computer, and blog after I have tested it at site in a couple of days from now.

Tuesday, 5 March 2019

Autologin with LXQt

Autologin isn't something I do normally, but on my computer that run LXQt, for what they are used for, it gets the computer up faster so it is useful. If you are using LXQt with SDDM which is the default display manager, it is pretty easy to use.

Simply edit /etc/sddm.conf.d/autologin.conf and enter the following text:
[Autologin]
User=xxx
Session=lxqt.desktop

The next time you reboot the system will automatically log in.

I did previously have the desktop now running LXQt set up to just need the password and not the user name to be specified (single user login) using a custom greeter with lightdm, as it had XFCE desktop environment, but the custom greeter was disabled when I upgraded to Buster, so using the LXQt autologin capability, which is simpler to set up than with lightdm, is the next best thing. LXQt is actually easier to set up some of those automation things than some DEs are. I may end up doing a startup display customisation on this computer to work around a small issue with the monitor setup and if so then that will be very easy to do with LXQt. I am already using the autostart on the laptop to run x11vnc and having this autologin as well will eliminate the need to log in manually to it before being able to use it.

Thursday, 7 February 2019

How to auto start x11vnc on LXQt or LXDE (including Raspbian)

LXQt is the desktop environment of the current edition of Lubuntu. Previous editions of Lubuntu used LXDE as the desktop environment. My personal preference is to use LXQt on Debian instead of XFCE on Debian, due to XFCE development being too slow (the same reason I switched most of my more powerful computers to KDE). I would only use LXQt on a computer like my Toshiab R500 which only has 2 GB of RAM, or in the case of the Raspberry Pi, they ship Raspbian using LXDE. I installed LXQt over the top of XFCE after installing Debian onto this laptop, and it works great.

LXQt and LXDE (and Raspbian) feature an easy autostart capability which can be configured from the GUI and can also be set up by placing a file called x11vnc.desktop into the ~/.config/autostart directory in the user's profile. If you use the GUI it creates the file with default settings. 

We want to use x11vnc to share the default desktop so that we can remote into it with a VNC client (I use Remmina) to remote control the laptop. This means I can use the laptop as my tethered desktop. The laptop sits on a docking station and can be quickly docked and undocked so the docking station can be left in place with all cables connected and all I need to do is bring out the laptop, dock it, turn it on and away we go.

The settings to be put into the desktop file (e.g. x11vnc.desktop) in the folder mentioned above are as follows. Note we have omitted -usepw as we are running it here without a password on a home network where there is no other user. If you want to use it with a password there are additional steps on first installing it to set the password and the extra switch to cause it to use the password which I have left out here.

[Desktop Entry]
Encoding=UTF-8
Type=Application
Name=X11VNC
Comment=
Exec=x11vnc -forever -display :0
StartupNotify=false
Terminal=false
Hidden=false
 

Saturday, 25 August 2018

KDE remote desktop sharing

One of the best things about KDE is the amount of apps they have available that are integrated into the shell. As XFCE lacks its own remote access integration you have to install x11vnc and muck around trying to get it to run as a service which I have yet to be able to complete. In KDE you have several apps available, I chose to use Krfb (RFB is the protocol that VNC uses) and it comes up as "Desktop Sharing" which is essentially the correct description of what I want to achieve.

With just a few clicks I was able to enable the desktop sharing and also enable it as unattended because I want to be able to connect to this desktop all the time without having to go to it to authorise a connection.

It will be interesting to see how Plasma develops in its latest high efficiency optimisation. It is quite possible some of my computers will be switched to KDE instead of XFCE but there is no huge rush as I just want to spend some time figuring out how everything works with KDE. Most of my PCs are fast enough to have few issues with the somewhat greater resource use in KDE and I will be keeping Debian as the base OS, no more Ubuntu for now. 

The only real thing with the Debian install of KDE is the clunky default logon theme which you'll want to change to the Breeze logon, for which you have to install additional packages. I last had a play with the Breeze logon when I had LXQt on one or two of my computers. Incidentally LXQt is now an option to install in the Buster alpha and the next release of Lubuntu will use it by default.

One of the reasons KDE looks good is because they are making steady progress towards integrating Wayland, something XFCE is falling further and further behind on. Pretty soon Wayland will replace X11 as the default display protocol and then some of the Linux desktop environments will not support it very well. Interestingly enough Ubuntu 17.10 installs Wayland by default (Xubuntu doesn't, so I won't have seen Wayland on anything yet). In Ubuntu 18.04 they reverted to Xorg after discovering Wayland still has some issues.

Mainpc at the moment is getting reinstalled with Debian and KDE because some sort of stupid crap bug resulted in an apt autoremove command removing a lot of core install packages including all of LibreOffice and some essential stuff, basically stuffing the system and making it unable to connect to the internet. So Debian 9.5 will be on it along with KDE and this will be only the second time I have tried KDE on one of my major computers that I use every day. This time hopefully I can make it stick (last time it was too hard to migrate from XFCE).

Saturday, 19 May 2018

Viewnior, Manjaro, Lubuntu, LXQt

Viewnior is another image viewer that is included in most Linux distros. It is significantly better than Eye of Gnome (EOG) because it can handle very large images. As such I expect Viewnior will become the default image viewer on all of my Linux computers.

I got to hear about Viewnior because I recently built a VM using Manjaro Linux. This distro is derived from Arch Linux, and compared to my ultimately abandoned efforts to get an Arch VM built from the core distro files, due to the complexity of their installation task which lacks a built in installer, Manjaro has been very easy to set up (using the XFCE edition). As this edition of Manjaro includes Qgis 3.0.2 I will be using this VM to run Qgis 3 on mainpc.

Since Lubuntu 18.04 was released I have now installed two computers with it: the NUC in my bedroom, and a Toshiba R700 laptop that I have. On both of them, I installed LXQt and sddm on top of Lubuntu, since the Lubuntu community hasn't yet got a version of LXQt they are willing to release for production yet. When you install sddm on top of Lubuntu you get the KDE Plasma login screen thrown in.

I have thought about putting Lxqt onto some of my other computers but it is only up to release 0.12 and in fact has a long way to go in terms of being usable and the development seems to be very slow. For now I am just leaving it with some VMs and Lubuntu computers mentioned above. However to make serverpc look nicer I have installed sddm with the Plasma Breeze theme and put some new icon themes into XFCE to make it look cooler.

Friday, 4 May 2018

Lubuntu LXQT still not ready for release, but can be manually installed.

As it will be generally known, the Lubuntu community are working towards migrating their platform to Lxqt. I have been testing a whole lot of VMs running Lxqt as a desktop environment and it looks good even if it is incomplete.

I have run it on my bedroom computer using a test install but there are issues with the wireless drivers which I am unable to make work and it may be a question of trying to fix these up or moving to the stable release of Lubuntu 18.04 until such a time as I can install Lxqt on top of that as the packages are not currently available to work on top of Lubuntu 18.04.

Failing that I may have to go back to Xubuntu and see if I can put Lxqt on top of it as it will be nearly the same and should work well. The issue with Lubuntu is while they have been working on the new release they have pushed it back yet again.

I decided to reinstall with Lubuntu and then added the lxqt install from the package manager. To get it working I also had to separately install the sddm display manager. This resulted in a Plasma login screen but set to log in to the Lubuntu QT session. At the moment there is an issue with PulseAudio but otherwise it seems to work very well and the wireless even worked during installation. So it looks like apart from the odd glitch I have it working. The Plasma login screen which is really nice looking is an added bonus.

The audio indicator which also apparently stops the up and down volume controls on the keyboard working is not a big deal in that configuration because the hardware volume control in this case is easily accessible. Perhaps this is more an issue with LXQT and will be fixed in a future release. The wireless driver is a much bigger issue and to find that is properly addressed and works flawlessly is a much more major issue and I am pleased that is resolved. There may be a way I can get Kodi's own volume controls to work with the keyboard in any case.

After doing some more work on this I uninstalled pulseaudio and are now using ALSA audio controls which seems to work perfectly and the volume control buttons on the keyboard also work properly and the master volume control for the system can also be set to full which produces much more output with a quiet audio source so that is what I have been able to make work with LXQT. So everything is great now.

Friday, 12 August 2016

Xubuntu vs Lubuntu

Well of course after playing with Xubuntu at home it didn't take much to have it installed on my work computer, a very old Wolfdale with a Celeron CPU and 4 GB of RAM. A very slow computer for its age, and also relatively old. Not sure exactly but I would guess around 6 years. This has been running Lubuntu up to now. The result of this test showed there is not really a great deal of difference performance wise, at least for the apps I use, between these two variants of Ubuntu. I understand that the memory footprint of Lubuntu itself may be slightly less. 

Nevertheless, the window manager in Xubuntu, which is not OpenBox, gives a much cleaner appearance to the operating system, a highly desirable characteristic for someone like me, who finds the interface improvements make for a very clean and polished appearance. The further advantage is that it is not difficult to install sophisticated apps like Google Earth. Therefore it is more of an all round system than either Mint, which is too resource hungry for old computers, or Lubuntu, which has too many components missing to make it easy to install power applications.