Active Topics
-
The N900 is now 15 years old! (7)
to Nokia N900 by Danct12 - 1 day, 17 hrs ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 2 days, 13 hrs ago -
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 4 days, 22 hrs ago - more...
|
2021-05-26
, 23:41
|
|
Posts: 30 |
Thanked: 24 times |
Joined on Mar 2014
|
#172
|
Originally Posted by wganis
Yes, it can.
Alo i have gemini x27 if i run sailfish can this method run well on my gemini thx a lot
Device: Gemini PDA 4G x27
Sailfish OS version: 4.1.0.24
Linux distribution: Debian Sid armhf
Guide to make it work:
I had to do the
Code:
devel-su ln -s /home/defaultuser /home/nemo
Then I followed the manual instructions in the first post instead of using GUI.
But one small change was needed - any line containing
Code:
/usr/share/sailfish-containers/guest
Code:
/var/lib/lxc/<container_name>/config
Code:
lxc.mount.entry = /usr/share/harbour-containers/scripts/guest mnt/guest none bind,create=dir 0 0
I am using the "debian-mouse-landscape.sh" script to start the Sailfish "part". (Needed to do
Code:
devel-su chmod +x debian-mouse-landscape.sh
What's not working:
- audio
- writing Fn+key symbols
What's working:
- running steam locomotive in terminal
- seems like everything else I've tried so far
Questions:
1) Is there anything I can do to fix the audio and keys, please? Shows no output hardware. Only dummy virtual output...
2) Also, any chance of running Anbox?
Thank you for any answer and for your great work.
Last edited by Mir57; 2021-05-27 at 00:09.
|
|
2021-05-27
, 08:21
|
|
Posts: 1,335 |
Thanked: 3,931 times |
Joined on Jul 2010
@ Brittany, France
|
#173
|
What is debian-mouse-landscape.sh and where can we see it? If it's meant to allow using a USB mouse in landscape, then check this out: https://github.com/sailfish-on-fxtec...ment-680788660 It will work for both SFOS and the container and even supports orientation changes.
The symlink between /home/nemo and /home/defaultuser is indeed the current workaround (and is also useful for many outdated apps on Openrepos) but hopefully we can avoid that soon if the forked daemon.py fixes the issue.
Thanks for noticing this issue with the mount entry. I think this is the first time this is reported, this will need some further investigation, as I have no idea where this comes from if it used to work fine on other devices.
Once we figure out the causes and solutions to all these issues, we'll need to work on a PR for harbour-containers and lxc-templates. And ideally, add some documentation too for future users, because LXC can be really great but can be intimidating at first (quirks with the installation we're discussing here, then desktop configuration).
Audio is working for me on my Pro1, with some limitations, like some sounds cannot be muted from the hardware volume buttons (which control the Sailfish volume): I think it mostly concerns terminal applications as I observed that only with the terminal bell and cmus music player. It's a non-issue for me though since the terminal bell usually is opt-in and configurable, and cmus has its own volume setting that can be set with - and + keys. I don't remember doing anything special to get audio to work, except maybe installing pavucontrol.
Regarding Fn keys, do you observe some output in xev? How keys are handled has never been clear to me on Pro1 either, and I believe it's mostly due to the fact that some keys might be intercepted by Sailfish before LXC sees them. For instance, the F(x) key on my Pro1 shows the SFOS homescreen even when I press it while in LXC, meaning its action is not constrained to the container (and I couldn't set it to Super in LXC). Same with Alt+Tab with Adam's taskswitcher daemon on, it intercepts the keybinding and triggers the SFOS taskswitcher (which is not necessarily a bad thing). The most annoying thing for me is I cannot distinguish Alt and the two yellow arrows, they all act as Right Alt, despite different keycodes in my xkb keymap and in xev output. Even if I try to alter them with Xmodmap and change one to Super for instance, the Xmodmap output will confirm that the change is in effect, but nothing will actually change. Xmodmap being ineffective may be related to using Xwayland. But I'm still desperately trying to distinguish Left Alt from Right Alt and I still haven't succeeded. I think I must have posted about it somewhere on Github or on Sailfish/Fxtec channels on IRC/Telegram/Discord.
My latest attempt was to compile kmonad (which went really smooth on ARM, the dev didn't know if it would work) since this is a really powerful tool for keyboard customization (supports multitaps, holds, layers, commands, macros, etc.) and I got it to run, but unfortunately I'm getting an error when trying to load my keyboard device into it (I did add a mount entry for /dev/input in my LXC config, but maybe I still have permissions issues to access it from LXC?). If we get this to work, I'm sure Fn keys could be supported too. However I still don't understand if Sailfish intercepting keys and changing their effect despite different keycodes is something we can work around (and if so, probably from Sailfish and not the container) or if it cannot be solved.
Last edited by Kabouik; 2021-05-27 at 08:33.
The symlink between /home/nemo and /home/defaultuser is indeed the current workaround (and is also useful for many outdated apps on Openrepos) but hopefully we can avoid that soon if the forked daemon.py fixes the issue.
Thanks for noticing this issue with the mount entry. I think this is the first time this is reported, this will need some further investigation, as I have no idea where this comes from if it used to work fine on other devices.
Once we figure out the causes and solutions to all these issues, we'll need to work on a PR for harbour-containers and lxc-templates. And ideally, add some documentation too for future users, because LXC can be really great but can be intimidating at first (quirks with the installation we're discussing here, then desktop configuration).
Audio is working for me on my Pro1, with some limitations, like some sounds cannot be muted from the hardware volume buttons (which control the Sailfish volume): I think it mostly concerns terminal applications as I observed that only with the terminal bell and cmus music player. It's a non-issue for me though since the terminal bell usually is opt-in and configurable, and cmus has its own volume setting that can be set with - and + keys. I don't remember doing anything special to get audio to work, except maybe installing pavucontrol.
Regarding Fn keys, do you observe some output in xev? How keys are handled has never been clear to me on Pro1 either, and I believe it's mostly due to the fact that some keys might be intercepted by Sailfish before LXC sees them. For instance, the F(x) key on my Pro1 shows the SFOS homescreen even when I press it while in LXC, meaning its action is not constrained to the container (and I couldn't set it to Super in LXC). Same with Alt+Tab with Adam's taskswitcher daemon on, it intercepts the keybinding and triggers the SFOS taskswitcher (which is not necessarily a bad thing). The most annoying thing for me is I cannot distinguish Alt and the two yellow arrows, they all act as Right Alt, despite different keycodes in my xkb keymap and in xev output. Even if I try to alter them with Xmodmap and change one to Super for instance, the Xmodmap output will confirm that the change is in effect, but nothing will actually change. Xmodmap being ineffective may be related to using Xwayland. But I'm still desperately trying to distinguish Left Alt from Right Alt and I still haven't succeeded. I think I must have posted about it somewhere on Github or on Sailfish/Fxtec channels on IRC/Telegram/Discord.
My latest attempt was to compile kmonad (which went really smooth on ARM, the dev didn't know if it would work) since this is a really powerful tool for keyboard customization (supports multitaps, holds, layers, commands, macros, etc.) and I got it to run, but unfortunately I'm getting an error when trying to load my keyboard device into it (I did add a mount entry for /dev/input in my LXC config, but maybe I still have permissions issues to access it from LXC?). If we get this to work, I'm sure Fn keys could be supported too. However I still don't understand if Sailfish intercepting keys and changing their effect despite different keycodes is something we can work around (and if so, probably from Sailfish and not the container) or if it cannot be solved.
Last edited by Kabouik; 2021-05-27 at 08:33.
| The Following User Says Thank You to Kabouik For This Useful Post: | ||
|
|
2021-05-27
, 10:53
|
|
Posts: 202 |
Thanked: 385 times |
Joined on Jul 2018
|
#174
|
Originally Posted by Kabouik
Scripts are from op here...
What is debian-mouse-landscape.sh and where can we see it? If it's meant to allow using a USB mouse in landscape, then check this out: https://github.com/sailfish-on-fxtec...ment-680788660 It will work for both SFOS and the container and even supports orientation changes.
The symlink between /home/nemo and /home/defaultuser is indeed the current workaround (and is also useful for many outdated apps on Openrepos) but hopefully we can avoid that soon if the forked daemon.py fixes the issue.
Thanks for noticing this issue with the mount entry. I think this is the first time this is reported, this will need some further investigation, as I have no idea where this comes from if it used to work fine on other devices.
Once we figure out the causes and solutions to all these issues, we'll need to work on a PR for harbour-containers and lxc-templates. And ideally, add some documentation too for future users, because LXC can be really great but can be intimidating at first (quirks with the installation we're discussing here, then desktop configuration).
Audio is working for me on my Pro1, with some limitations, like some sounds cannot be muted from the hardware volume buttons (which control the Sailfish volume): I think it mostly concerns terminal applications as I observed that only with the terminal bell and cmus music player. It's a non-issue for me though since the terminal bell usually is opt-in and configurable, and cmus has its own volume setting that can be set with - and + keys. I don't remember doing anything special to get audio to work, except maybe installing pavucontrol.
Regarding Fn keys, do you observe some output in xev? How keys are handled has never been clear to me on Pro1 either, and I believe it's mostly due to the fact that some keys might be intercepted by Sailfish before LXC sees them. For instance, the F(x) key on my Pro1 shows the SFOS homescreen even when I press it while in LXC, meaning its action is not constrained to the container (and I couldn't set it to Super in LXC). Same with Alt+Tab with Adam's taskswitcher daemon on, it intercepts the keybinding and triggers the SFOS taskswitcher (which is not necessarily a bad thing). The most annoying thing for me is I cannot distinguish Alt and the two yellow arrows, they all act as Right Alt, despite different keycodes in my xkb keymap and in xev output. Even if I try to alter them with Xmodmap and change one to Super for instance, the Xmodmap output will confirm that the change is in effect, but nothing will actually change. Xmodmap being ineffective may be related to using Xwayland. But I'm still desperately trying to distinguish Left Alt from Right Alt and I still haven't succeeded. I think I must have posted about it somewhere on Github or on Sailfish/Fxtec channels on IRC/Telegram/Discord.
My latest attempt was to compile kmonad (which went really smooth on ARM, the dev didn't know if it would work) since this is a really powerful tool for keyboard customization (supports multitaps, holds, layers, commands, macros, etc.) and I got it to run, but unfortunately I'm getting an error when trying to load my keyboard device into it (I did add a mount entry for /dev/input in my LXC config, but maybe I still have permissions issues to access it from LXC?). If we get this to work, I'm sure Fn keys could be supported too. However I still don't understand if Sailfish intercepting keys and changing their effect despite different keycodes is something we can work around (and if so, probably from Sailfish and not the container) or if it cannot be solved.
|
|
2021-05-27
, 11:11
|
|
Posts: 1,335 |
Thanked: 3,931 times |
Joined on Jul 2010
@ Brittany, France
|
#175
|
Oh, right, thanks for reminding me. I never used those scripts so I can't comment, but it should no longer be necessary to use different scripts to start the container in landscape or portrait mode (the GUI should be able to do it once we find what breaks it), and no script is needed to enable or disable mouse support either (elros34's patch and qt5 plugin, see the URL I posted above, take care of it automatically, detect when a mouse is connected or not, and adapt to the orientation dynamically).
I wouldn't recommend using those custom scripts if edp17 can confirm that they no longer provide additional functionality compared to elros34's patch, at least not while debugging the other issues, since the scripts seem to use qxcompositor instead of qxdisplay.
I wouldn't recommend using those custom scripts if edp17 can confirm that they no longer provide additional functionality compared to elros34's patch, at least not while debugging the other issues, since the scripts seem to use qxcompositor instead of qxdisplay.
|
|
2021-05-27
, 17:12
|
|
Posts: 30 |
Thanked: 24 times |
Joined on Mar 2014
|
#176
|
Originally Posted by Kabouik
It is the script you provided in the first post, used after installing qxcompositor. Did not try mouse yet, did not all of the additional configuration you provided in this recent link.
What is debian-mouse-landscape.sh and where can we see it? If it's meant to allow using a USB mouse in landscape, then check this out: https://github.com/sailfish-on-fxtec...ment-680788660 It will work for both SFOS and the container and even supports orientation changes.
Originally Posted by Kabouik
"LXC can be really great" - indeed it is.
Once we figure out the causes and solutions to all these issues, we'll need to work on a PR for harbour-containers and lxc-templates. And ideally, add some documentation too for future users, because LXC can be really great but can be intimidating at first (quirks with the installation we're discussing here, then desktop configuration).
Originally Posted by Kabouik
This is what actually holds me from using it as a normal device... As was previously stated, it also breaks any audio in Sailfish OS meanwhile.
Audio is working for me on my Pro1, with some limitations, like some sounds cannot be muted from the hardware volume buttons (which control the Sailfish volume): I think it mostly concerns terminal applications as I observed that only with the terminal bell and cmus music player. It's a non-issue for me though since the terminal bell usually is opt-in and configurable, and cmus has its own volume setting that can be set with - and + keys. I don't remember doing anything special to get audio to work, except maybe installing pavucontrol.
Originally Posted by Kabouik
How could I do this test? Do you have any guide, how to launch xev and see the output?
Regarding Fn keys, do you observe some output in xev? How keys are handled has never been clear to me on Pro1 either, and I believe it's mostly due to the fact that some keys might be intercepted by Sailfish before LXC sees them. For instance, the F(x) key on my Pro1 shows the SFOS homescreen even when I press it while in LXC, meaning its action is not constrained to the container (and I couldn't set it to Super in LXC). Same with Alt+Tab with Adam's taskswitcher daemon on, it intercepts the keybinding and triggers the SFOS taskswitcher (which is not necessarily a bad thing). The most annoying thing for me is I cannot distinguish Alt and the two yellow arrows, they all act as Right Alt, despite different keycodes in my xkb keymap and in xev output. Even if I try to alter them with Xmodmap and change one to Super for instance, the Xmodmap output will confirm that the change is in effect, but nothing will actually change. Xmodmap being ineffective may be related to using Xwayland. But I'm still desperately trying to distinguish Left Alt from Right Alt and I still haven't succeeded. I think I must have posted about it somewhere on Github or on Sailfish/Fxtec channels on IRC/Telegram/Discord.
Originally Posted by Kabouik
Would be cool.
My latest attempt was to compile kmonad (which went really smooth on ARM, the dev didn't know if it would work) since this is a really powerful tool for keyboard customization (supports multitaps, holds, layers, commands, macros, etc.) and I got it to run, but unfortunately I'm getting an error when trying to load my keyboard device into it (I did add a mount entry for /dev/input in my LXC config, but maybe I still have permissions issues to access it from LXC?). If we get this to work, I'm sure Fn keys could be supported too. However I still don't understand if Sailfish intercepting keys and changing their effect despite different keycodes is something we can work around (and if so, probably from Sailfish and not the container) or if it cannot be solved.
| The Following User Says Thank You to Mir57 For This Useful Post: | ||
|
|
2021-05-27
, 20:34
|
|
Posts: 14 |
Thanked: 28 times |
Joined on May 2021
|
#177
|
Originally Posted by Kabouik
I gave this a go, but I'm getting the same error as always when I run
Can you guys try to install the latest harbour-containers release (as we did before), then replace daemon.py with the one on my fork (same as before too), and then also replace the content of /usr/share/harbour-containers/scripts/guest/setups/debian.sh by that of this version, and only after that try to create a new Debian Sid container?
Code:
[defaultuser@Xperia10 ~]$ /usr/bin/qxdisplay --wayland-socket-name "../../display/wayland-container-0"
Code:
[D] unknown:0 - Using Wayland-EGL [D] unknown:0 - Specified Desktop file does not exist "/usr/sha re/applications/qxdisplay.desktop" [W] unknown:0 - Theme dir "/usr/share/themes/jolla/meegotouch/z 1.5/" does not exist [W] unknown:0 - Theme dir "/usr/share/themes/jolla/meegotouch/z 1.5/" does not exist
| The Following User Says Thank You to spoofykid For This Useful Post: | ||
|
|
2021-05-27
, 21:26
|
|
Posts: 202 |
Thanked: 385 times |
Joined on Jul 2018
|
#178
|
Originally Posted by spoofykid
Did you install all packages from op?
I gave this a go, but I'm getting the same error as always when I run
which isCode:[defaultuser@Xperia10 ~]$ /usr/bin/qxdisplay --wayland-socket-name "../../display/wayland-container-0"
So, I'm sure what I'm doing wrong - Maybe I'll try destroy the containers, delete all files from /home/.lxc, and try again. This is Xperia 10 on 4.1.0.24 with defaultuser.Code:[D] unknown:0 - Using Wayland-EGL [D] unknown:0 - Specified Desktop file does not exist "/usr/sha re/applications/qxdisplay.desktop" [W] unknown:0 - Theme dir "/usr/share/themes/jolla/meegotouch/z 1.5/" does not exist [W] unknown:0 - Theme dir "/usr/share/themes/jolla/meegotouch/z 1.5/" does not exist
Code:
Downloads:
harbour-containers
lxc-templates-desktop
qxdisplay
|
|
2021-05-27
, 21:52
|
|
Posts: 14 |
Thanked: 28 times |
Joined on May 2021
|
#179
|
Originally Posted by levone1
Yes. Multiple times. Installed Debian Sid - armhf and arm64 - multiple times, as well as Kali current - armhf and arm64. I installed both through the manual way and the GUI way. The "waiting for xwayland" screen does display afterward, which I imagine wouldn't happen if qxdisplay wasn't installed?
Did you install all packages from op?Code:Downloads: harbour-containers lxc-templates-desktop qxdisplay
I did double check by running this in the folder where those rpm files were downloaded:
Code:
devel-su zypper install lxc-templates-desktop-1.1-4.noarch.rpm qxdisplay-0.1-2.armv7hl.rpm harbour-containers-0.4-1.armv7hl.rpm
Last edited by spoofykid; 2021-05-28 at 00:37.
|
|
2021-05-28
, 02:42
|
|
Posts: 202 |
Thanked: 385 times |
Joined on Jul 2018
|
#180
|
Originally Posted by spoofykid
For the errors about .../usr/share/themes..., you could try
Yes. Multiple times. Installed Debian Sid - armhf and arm64 - multiple times, as well as Kali current - armhf and arm64. I installed both through the manual way and the GUI way. The "waiting for xwayland" screen does display afterward, which I imagine wouldn't happen if qxdisplay wasn't installed?
I did double check by running this in the folder where those rpm files were downloaded:
It said they were already installed and there was 'nothing to do'.Code:devel-su zypper install lxc-templates-desktop-1.1-4.noarch.rpm qxdisplay-0.1-2.armv7hl.rpm harbour-containers-0.4-1.armv7hl.rpm
Code:
devel-su pkcon install --allow-reinstall -y sailfish-content-graphics-default-z1.0-base sailfish-content-graphics-default-z1.25-base sailfish-content-graphics-default-z1.5-base sailfish-content-graphics-default-z1.75-base sailfish-content-graphics-default-z2.0-base sailfish-content-graphics-closed-z1.0 sailfish-content-graphics-closed-z1.25 sailfish-content-graphics-closed-z1.5 sailfish-content-graphics-closed-z1.75 sailfish-content-graphics-closed-z2.0
 |
| Tags |
| application, development, linux |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 18:17.
Another thing to test: @mibry on Discord observed that there has been commits to harbour-containers after the latest .rpm release, including one that has to do with the container installation. From what I see in the commit history, this should only influence XFCE setup and not the issues you're facing, but it doesn't hurt to fix that before we forget.
Can you guys try to install the latest harbour-containers release (as we did before), then replace daemon.py with the one on my fork (same as before too), and then also replace the content of /usr/share/harbour-containers/scripts/guest/setups/debian.sh by that of this version, and only after that try to create a new Debian Sid container? Make sure both daemon.py and debian.sh are executable (devel-su chmod +x /path/to/file). If my fork breaks things and creates new bugs you don't observe with vanilla daemon.py, please report and tell if your user is named nemo or defaultuser, you device and SFOS version, and whether you have an active symlink between /home/nemo and /home/defaultuser.
If your harbour-containers is already showing an empty GUI and you can't interact with it, then destroy your existing Linux containers using lxc-destroy as described in a post above (be sure to backup your rootfs from /home/.lxc and config file from /var/lib/lxc before if your container has worked in the past and has some value to you).
Last edited by Kabouik; 2021-05-26 at 01:06.