Jump to content

matf-kabouik

Members
 View Profile  See their activity

  • Content Count

    211

  • Joined

  • Last visited

  • Days Won

    7

 Content Type 

Posts posted by matf-kabouik

    Pro1 and Pro1 X design change to use Snapdragon 662, no new devices before August 2021

    in Pro1 - Thoughts & questions

    Posted · Edited by matf

    I could wait even longer. The Pro1x is a device I plan on using for years, it's an investment for the long term and being niche, I know it won't get iterations and updates every year. I'd rather wait years and have it finally delivered with no compromises. An older SOC is not an issue for me, I plan on using mainline eventually, which also answers the question on whether I care about certification (however, I believe having Android as an option really increased the backer base and was therefore likely a sound decision). My plan is to use the device to run Mobile Linux, meaning it's best if the SOC is actively being worked on by the Linux/Mainline community. As desktop applications in Linux can also be a bit demanding, I would like raw performance on par with the msm8998 (which I tried already and can confirm it's enough for what I need, but slower could be an issue).

    I am not sure there is still room for reconsidering the choices at this stage, though. There are probably constraints we don't see as customers. But if I'm asked whether I could wait or not, then definitely, I could, and I would vastly prefer that.

    • Like 9

    Pro1-X just arrived today, what a beautiful device.

    in Pro1 - Thoughts & questions

    Posted · Edited by matf

    1 hour ago, EskeRahn said:

    Suggesting anything that is illegal is clearly outside what is acceptable in here, I hid you comment, so you will have to make it again without that.

    You're implying I suggested it. I did not, I think I even wrote the opposite, and I didn't detail how to do it either.

    What I did say is there is no technical/hardware limitation to running Alien Dalvik and other paid Sailfish X software on a Pro1, as was also posted by others on Twitter, including a former Jolla employee. However I made it clear that there are commercial and legal limitations (i.e., the licence cannot be purchased and flashed to anything else than an official device, which in turns creates technical barriers), this is not a secret in any way. I encouraged buying a licence to support Jolla if going this route, because the main risk is Jolla being upset enough to make it significantly more difficult, however that seems unlikely if people trying to use their licence on unofficial devices do it after properly paying for their licence and don't expect support. On a second thought, that could be taken as incitation, apologies for that. I was just trying to be factual and thought that was not out of line since I warned that this would probably be a breach of EULA.

    Could you just edit the original message to leave my answer about Anbox?

    • Like 3

    Desktop Linux on Pro1 without sacrificing telephony: LXC containers in SailfishOS (video)

    in General Discussion

    Posted · Edited by matf

    On 12/3/2020 at 7:27 PM, claude0001 said:

    I had seen this post already quite some time ago, but did not have time to comment up to now (or was too lazy ...).

    Thanks for sharing this. Your set-up looks quite impressive. I use my Pro1 in a similar way, but -- for now -- using LineageOS as the basis (see this post). I do have a few questions, that you may or may not be able to answer:

    * As long as all alternative OS'es (Lineage, Sailfish, UbuntuTouch, ...) use the same original Linux kernel from stock Android 9 and its (closed-source) drivers, we will never get things like hardware-accelerated graphics in a "desktop" Linux install. So, do you actually think your Sailfish setup is superior in terms of "hardware-support" to all the CHROOT/PROOT solutions for using desktop-Linux on Android? If not, what other advantages do you see?

    * In your set-up, you seem to be using the touchscreen as a "direct input" interface. The standard way of using a (desktop) Linux-chroot on Android is to access an X-Session running in the chroot via a remote desktop (RDP or VNC) client. This is quite convenient, as most of those offer the possibility to emulate a touchpad, as well as several mouse buttons. Also, many clients allow gesture-based zooming of the Linux-session which is often useful given the small screen size. Is this possible using your XWayland solution on Sailfish?

    * In Android, the security model can be nuisance in this kind of use case, as it prevents fully transparent mounting of Android filesystems in the Linux desktop environment at least for its "sacred" partitions (as far as I understand). How is it on Sailfish? Can you mount any filesystem of the parent OS in the container so that it is writable (for root at least)?

    Thanks for sharing your setup too, it looks very interesting and, being running in Android, it undoubtedly can be used by many more people than any Sailfish solution! I'm very happy to hear about users using their device as a desktop UMPC.

    1. You two know much more than I do about hardware acceleration and how it works under the hood, to me this is just like trying to understand those green symbols falling down in the matrix, so I won't try to reply accurately to that question. All I can say is the developer of sailfish-containers told me that, theoretically, HW acceleration in LXC could be solved by adding hybris-mobian repository, installing libhybris, and patching wlroots. Containers could then run in Wayland instead of XWayland/Qxdisplay, but this hasn't been tested as far as I know. And who knows how much work would "patching wlroots" be. As for whether LXC is superior to chroot or not, I honestly don't have an educated answer, but I always heard that chroots has a few more limitations, like systemd or the like.

    2. I don't think this is possible using the XWayland solution in Sailfish. But it may be possible to use remote desktop solutions too. I know it is possible to use Xephyr/Xnest too, and that the implementation is a bit different. I try that quickly when I wanted to get a software cursor rendered on the screen (which is now fixed in XWayland), and I know it also offered more possibilities to manipulate X settings, like xmodmap (which has no effect in XWayland), although there were different limitations for touch use which made me stick to XWayland. XWayland is definitely suboptimal and merely a way to deal with the Wayland limitations in SailfishOS that Raksura mentionned. It would be interesting indeed to investigate remote desktop solutions as long as the performance and security remains the same, especially if they offer better support for right clicks.

    3. That here is a significant advantage of the implementation of LXC containers in SailfishOS. I *believe* you can mount any folder you want, and you will have write permissions if you want to. I only mount my Sailfish $HOME and my SD card.

    • Thanks 1

    Pro1 X Qwerty Layout (Not Shifted)

    in Pro1 - Thoughts & questions

    Posted · Edited by matf

    I'm not sure I understood what you meant about qwertz. Can you please elaborate @EskeRahn?

    Is that related to not all keys having a secondary layer for a second colour? I guess if keys are redone to change the layout, it's not changing much to the production to change which keys get a secondary layer in the first place. Their plans for Scandic already shows new keys with secondary colour compared to what we currently have on Pro1 or in other Pro1x layouts (N and K for instance).

    The issue would most likely be to use the previously produced keypads, to avoid wasting parts.

    Pro1 X Qwerty Layout (Not Shifted)

    in Pro1 - Thoughts & questions

    Posted · Edited by matf

    I have completed the draft on the gist with an additional layout with only two colours, and larger labels to make it more realistic considering what we currently have on the Pro1.

    I also added that our previous us-intl layouts were partly incorrect, because some keys had labels that should not exist, there were a couple duplicates, and also those layouts were showing a mix of third-level and fourth-level characters. This is an issue because our colour hint suggests that AltGr produces these characters, not Shift + AltGr. Mixing them makes it non standard and hard to follow, even if it is sometimes to give priority to more common symbols. Another issue is there are more keys with third level characters than keys with fourth level characters, so choosing to show fourth-level characters would result in no blue label on some keys, despite them actually having some symbols to show when combined with AltGr. Those previous layouts we made were all based on an us-intl layout that was posted here, but turns out it was a little more featureful than the standard (and had one duplicate symbol). I do not feel bravehearted enough to redo them all from scratch, I think it's fine if we just acknowledge this mistake and stress that F(x)tec folks should not do the same mistake. If we want to add extra characters, I suggest we do it on keys that are still empty on third and fourth levels, like F, G, H, J, K, X, V and N but leave everything standard on other keys so that our layout is just us-intl on steroids, not us-layout with custom trade-offs. See the corresponding paragraph at the end of the gist.

    Considering the constraints (two colours max being a very likely constraint), my favourite is Fig. 4:
     

    Quote

     

    99204068-60fd4000-27ac-11eb-865d-f17d60f

    Fig. 4. Layout with all us-intl labels and just two colours on keys for easier production: white for main keys, blue for AltGr modifiers and symbols, as well as the Fx key (Super) which would be cool for the Pro1x limited edition. us-intl alpha keys could be upper case if preferred. Fn is labelled in smaller size and in the top right of its key as a visual hint of where to look for function key combinations: top right, white, smaller. The same would work with bottom right if preferred. Symbols instead of text are used for function keys for space saving (except Del, as it is both more straightforward and easier to distinguish from ⌫ than ⌦). Keys are overall labelled in larger font than the other examples to make this layout realistic and similar to the current Pro1 layouts. It is still legible, which shows that this layout could work with the actual size of the Pro1/Pro1x keys.

     

     

    Else, with three colours, Fig. 3 would be my favourite (provided the us-intl keys are fixed).

    But of course, we could cook everything in a different way. For instance, the us-intl labels could be removed, freeing blue for something else, and then printing the Fn key as well as the associated function symbols in blue. That would work for me too. However, I believe an us-intl layout being conspicuously visible straight from a product page on the F(x)tec website without investigating any software workarounds for international symbols would be important to convince international users not already represented by Qwerty, Scandic, Qwertz and Azerty. Else, I'm sure the vast majority of users would probably not look for software solutions, and just consider this device is only for English/Scandic/German/French speaking people.

     

    • Like 1
    • Thanks 2

    [Community Build][3.3.0.16][Updated 18th Aug] Sailfish OS for Fxtec Pro1

    in How Tos

    Posted

    On 10/2/2020 at 1:21 AM, jamescarruthers said:

    I am finding Android to be pretty horrible to use. I would switch to Sailfish to try it but in order to not to have to dual-carry another phone for work I have to have WhatsApp for my work SIM.

    I know Android apps aren't officially supported but is there some sort of unofficial way of getting the Android app ability to work?

     

    I can confirm Aurora and Whatsapp would work on a Pro1 running SFOS but you would need rpms from a XA2 (meaning license + device) and it wouldn't be legal. However if you purchase a XA2 license alone and ask the community it would at least be close to morally acceptable (in my opinion, but who am I to tell something illegal is morally acceptable? D:).

    • Haha 1

    Desktop Linux on Pro1 without sacrificing telephony: LXC containers in SailfishOS (video)

    in General Discussion

    Posted · Edited by matf

    PoliticalDirtyAfricanporcupine-size_restFewWideKillerwhale-size_restricted.gif

     

    LXC is such a good combination with the Pro¹ that it might be worth a video on the official forum, even though I'm not very active here:

    - LBRY for good connections (big file): https://open.lbry.com/@Kab:7/LXC_sailfishos_Pro1:b?r=BZ8k2XPpJvbZhRttC15UQs34pYd2SS97

    - Youtube for slower connections: https://youtu.be/-dgD5jci8Dk

     

     

    DESCRIPTION
    Sorry for the annoying accent. This is an overview of full desktop Linux distributions running as LXC containers in SailfishOS, on a F(x)tec Pro1 qwerty slider phone. If not interested in Sailfish itself, jump to 06'23" for Kali XFCE (fresh install) or 08'40" for Debian i3-gaps (configured install).

    I am not affiliated to SailfishOS or F(x)tec, and am merely a community member using sailfish-containers since a few months. This application is being developed by r3vn (https://github.com/sailfish-containers) and is inspired by previous work by elros34 and Preflex on chroot solutions
    and Xwayland.

    Battery use is similar with and without containers running, one can go through the day with a full charge and light to normal use. The Pro¹ does not have a bleeding edge SOC, but the performance is good enough for what I use it for, and using this SOC may actually be an advantage for overall Linux support (drivers, mainlining task).

    It is possible to use the us-intl layout and deadkeys on the hardware keyboard, this is how I use it. There is also support for external keyboard and mouse, meaning we're only missing hw-decoding and, most importantly video-out through the USB-C port, for ultimate "Convergence" where we'd get a full desktop experience and not a mobile OS with an external display. Hopefully someone will find a way to make video-out work on Sailfish so we can get the perfect Linux travel companion.

    Content:
    [00:00] Introduction to Sailfish on the Pro¹ 
    [00:44] Sailfish multitasking view 
    [01:11] Hardware keyboard support in SailfishOS 
    [02:31] Application to install/manage Linux containers 
    [04:14] Foreword on the known limitations 
    [05:43] Kali XFCE (fresh install) 
    [08:40] Debian i3-gaps (configured install) 
    [08:58] Darktable 
    [09:17] Short demo of i3wm for those not familiar with tiling WMs 
    [11:23] Firefox desktop 
    [12:10] Quick peek at the similarity of my desktop environments on a full size computer and on the smartphone 
    [12:49] Keybindings in Firefox 
    [13:25] Video playback performance and multitasking 
    [14:28] Document editing with Libreoffice 
    [16:12] Multitasking example 
    [16:45] Gimp 
    [17:30] nnn terminal file manager and Nautilus 
    [18:41] Using Onboard virtual keyboard on touch-only devices 
    [20:47] Conclusion and some words about device compatibility, performance and battery use 

    Links:
    sailfish-containers repository, https://github.com/sailfish-containers

    • Like 1
    • Thanks 12

    Pro1 X Qwerty Layout (Not Shifted)

    in Pro1 - Thoughts & questions

    Posted · Edited by matf

    Works for me. At this point I think what would determine whether we use the most minimal symbols or those more visually complex with corners or bars is whether we enclose them between brackets or not.

    Note that we could also just write "Fn" on the top right corner of the modifier key, and then show those symbols on their respective top right corner too, I may be equally clear that Fn is needed to use those functions. While AltGr would be in a distinct colour similar to us-intl symbols. Of course for layouts with no us-intl symbol labels, the issue vanishes because only two label colours are needed.

    • Like 2

    Pro1 X Qwerty Layout (Not Shifted)

    in Pro1 - Thoughts & questions

    Posted · Edited by matf

    If we suggest symbols to keep the labels short, I think those are more or less common (maybe not conventional, but at least straightforward):

    Page Up: ⇞

    Page Down: ⇟

    Home: ↖, ↸, ⭶, ⤒, ⇤, ⌜, ⇱

    End: ↘, ⭸, ⤓, ⇥, ⌟, ⇲

    Del: ␡, ⌦

    Ins: ⎀

    Source. Some are my own invention and may not make sense, some others are actually borrowed from Tab, but there wouldn't be any ambiguity in our case.

    We could propose a keyboard layout with that and only two label colours, with or without brackets.

    Note that ⎇ is also standard for Alt, albeit rarely used. This could be another way to distinguish Alt and AltGr too, but I must admit I prefer the modifiers to be written in letters as they are currently. Looks tidier and easier to understand in my opinion. I wouldn't mind the 6 functions (PgUp, PgDn, Home, End, Delete, Backspace) to be using their icons if that's the only way to have them printed large enough and convince F(x)tec, though.

    My personal preference would be ⇞, ⇟, ↖, ↘, ⌦, ⎀, because they look minimal yet self-explanatory and keep the keyboard relatively clean.

    • Like 2

    Pro1 X Qwerty Layout (Not Shifted)

    in Pro1 - Thoughts & questions

    Posted · Edited by matf

    After @EskeRahn's comment, I heard from someone I can't name that, indeed, distinct label colours in addition to white are unlikely (but we never know). Blue might be possible, but I mentioned that this would mean changing the Fx label so there's no firm answer on that either.

    In any case, I believe we could send our message almost as is and keep the images we have, but add a couple sentences to acknowledge that layouts with multiple label colours are difficult to produce. However, this could be dealt with by printing only us-intl labels and not Fn keys (I think it's fine if they're hidden but learned by users, it's only 5 or 6 key combinations). Or the opposite if us-intl is deemed too specific, but we already cover this in the message.

    Other workarounds include printing Fn combinations in white like normal keys, but have them written on the right instead of the left or the center, which shows they are secondary keys and the left symbol is primary. Backspace would become `⌫ Del` instead of just `⌫`. Another way could be to mark functions with brackets (just an example), i.e., the modifier would be labelled `[Fn]` and then functions on other keys could be between brackets too, like `◀ [Home]`. This would make labels longer for no huge benefit, but those functions usually have dedicated symbols too: `◀ [↖]` would work too and keep that relatively short. I personally think just writing two white labels on keys, left- and right-aligned, respectively, would work, but it doesn't hurt to give them additional suggestions to make sure they don't rule out all our proposal because we based it on multiple colours.

    • Like 2

    AZERTY layout proposal

    in Pro1 - Thoughts & questions

    Posted

    Hey @Slion, how about swapping the left AltGr with Fn? This would make it closer to the current layout and hence maybe increase chances of having it approved. That's one of the reasons which contributed to making this choice for the qwerty proposal and it would be consistent. Both AltGr are still independent so one could configure Alt_L on the left AltGr if they don't need two Alt_R, and that would make easy Ctrl+Alt combinations on both sides. Also, Fn+Alt would be easier by default, which could be useful for Alt+F1-12. Ctrl+F1-12 would become a tad more difficult, however.

    Is it necessary to have Shift and shifted symbols on digits in yellow for color hints despite it being the convention? Without that you could have Fn+key functions in yellow instead.

    • Like 1

    Pro1 X Qwerty Layout (Not Shifted)

    in Pro1 - Thoughts & questions

    Posted · Edited by matf

    That's true but given those labels are just for third-level symbol, that would probably be acceptable anyway in my opinion. People who need them just need to be able to find them until they get used to the layout (which they might already be since it's standard). 

    At worst, F(x)tec could always change the hue for something slightly lighter, or go for a layout with just intl labels on the alpha keys. Also, here we used the online editor because it is convenient and looks good, but in practice the labels seem to be printed in bigger and bolder font on the Pro1.

    • Like 1

    Pro1 X Qwerty Layout (Not Shifted)

    in Pro1 - Thoughts & questions

    Posted · Edited by matf

    Absolutely, and maybe F(x)tec won't deem our proposal relevant anyway. :> In any case, I guess if they accept a layout change, it will be featured in an IGG update and those who got the Christmas perk should get the opportunity to get their device as announced and for Christmas, or wait more for a unit with the upgraded layout, so it'd still be better to send the suggestion early enough.

    My personal favourite is now the 2nd one (with full us-intl labels). Initially I was not a big fan of printing all labels, yellow international labels used to make the keyboard very busy and I thought non-us-intl users would be annoyed. However I think blue is discreet enough and does not clutter the keyboard, while making it a very robust option in all languages. Having a Linux phone with the normal us-intl layout and fully standard alpha-digit block would be quite something in the tech world, in my opinion. It all also depends on whether they would replace the basic qwerty with that one, or just add an the international variant while keeping the simple one as an option.

    • Like 1

    Pro1 X Qwerty Layout (Not Shifted)

    in Pro1 - Thoughts & questions

    Posted · Edited by matf

    I just updated the gist with the missing pictures, and fixed a couple aesthetic issues in the others (no layout change, just fixing some alignment inconsistency when having or not having us-intl labels, and removing us-intl labels that were actually visible in dark grey in the first layout). Looks OK to me now.

    If you guys agree, maybe we shouldn't wait too much before sending it to porters and to Liangchen. It would maximise our chances to get it reviewed before they start production (the Xmas perk should already be under production actually).

    • Like 1

    Pro1 X Qwerty Layout (Not Shifted)

    in Pro1 - Thoughts & questions

    Posted · Edited by matf

    I tried to add arguments to strengthen our proposal, and also emphasized that all this was a discussion where everyone was welcome, not just one isolated community member's suggestion (but I'm very grateful to Craig for starting the initiative and taking leadership here).

    I wanted you guys to see the revision history but didn't want to force anyone (myself included) into using a word processor and eventually get cancer, so I put my changes in a Gist that you can all review, comment and maybe edit directly (not sure). You can view the revisions from the "Revisions" tab at the top.

    Those are just humble suggestions to make our point more robust, but maybe what I did doesn't go in the right direction. You tell me. I initially put more arguments in my first draft, but I got punished after criticizing word processors when Firefox crashed and lost all my edits before I commited them, I had to restart from scratch and forgot some points.

    • Like 3
×
×
  • Create New...

Important Information

Terms

  I accept