Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

39 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Just keep in mind that this app only works because SELinux is not enforcing. Normally apps wouldn't be allowed to do that (side note: why are the discretionary permissions even allowing this?). So when the build goes official, that app won't work anymore.
  2. You are right, I wanted to make that the point of my reply (but somehow forgot to include it): So far I've only seen anecdotal evidence for either claim, and no reliable statistics (and I am not sure how one would get these). So I wouldn't discount it on the basis of stability claims some people made at some time, but rather because it does not fit either SD cards or Android in general (how would you even use its features?). Well, it depends on what you are benchmarking, certain operations will be faster on any COW filesystem (copying, as an easy example), but then random writing will slow down things a lot. I don't think Android will do much random writing to SD cards (it mostly reads what you put on there, right?), but then it will also not do anything where COW is an advantage.
  3. To defend one of my favourite filesystems: I have my daily driver notebook running on btrfs since 2014, fully stable. And the features that the COW nature of it offers are vastly underestimated: You may think about subvolumes and snapshotting them, but did you know that with reflinking you can have snapshot semantics on a per-file level, without any need to create subvolumes? You don't need to think in advance where you want to set the boundary for a snapshot, you just reflink copy the files that you want to "snapshot". Have a huge build tree with icky or non-existent version control where you want to experiment in? Just `cp --reflink` it, the copy won't take more space than the metadata, do your experiment and just move the folder back if you want to revert. No need to create a subvolume first or anything. Oh, and SailfishOS uses it on it's internal storage as well, and my Jolla still hasn't died, despite many many factory resets (which are based on btrfs subvolumes). But… I also wouldn't use it on an SD card. The strict COW nature of btrfs means that at some point you have to defragment (read: fully rewrite) it, and that will kill your SD card, no matter how expensive and high-end it was.
  4. I am really curious to know what the problem was, if it's not too much work to explain 😇 If you're referring to not having LED notifications (except charging), I can confirm. Notification vibration I have though. @Polaris: Just to make sure, you haven't accidentially disabled vibrating notifications? Not only the global setting, but maybe just for the apps you use? Sometimes things can get weird and the default notification channel settings may not be what you'd expect (I know that I had chat notifications for a certain app completely hidden by default, for some reason). Many here seem to find this important, but, just to make sure, you all know that ext4 on sdcards works as well, and it supports a maximum size of 1 Exbibyte (which is most definitively larger than whatever the SD reader of the pro1 accepts)? For me personally the TWRP would be the most important thing. It feels really dangerous switching between branches and cherry-picking patches without having a way to go back (that includes userdata) 😅
  5. So, now that the topic of keyboard mapping has come up here already, I want to add a bit of (what I hope is) constructive criticism. But first off I want to clarify that I am and will stay grateful for @tdms (and mccrearys) work on this port, without which my Pro¹ be not much more than an expensive toy. And, those who do all the unpaid community work (i.e. @tdm) have the right to decide how this project goes, until we start writing patches ourselves we should only offer suggestions. So, here we go: If I understand @Craigs suggestion right, he would have the semantics of the "slanted arrow" keys and the "fxtec logo" key swapped, with the logo key acting as a modifier and the arrow keys not (but instead being shortcuts and/or a standalone key like slash). I see the appeal of being able to remap one of those keys, but I am afraid that for a lot of other people that would greatly diminish the typing experience. The keyboard we have has the shift, "slanted arrow" and even ctrl modifiers on both sides, and that speeds up typing as you can press the modifier key with one thumb and the "main" key with the other. Even with sticky modifiers it speeds up typing, or at least makes it more comfortable. With @tdm having already implemented his idea of an in-kernel key mapping, I feel doubly bad about criticizing it now (please don't take it the wrong way)... But still, I think this is the wrong way forward. I'll leave aside any architectural or idiomatic aspects, as that is in the end only personal preference; instead I want to point out one Feature that this approach conflicts with (as far as I know): The sticky modifiers. If the keyboard is declared to be of type "ALPHA" (i.e. be a thumb-typing keyboard), we get sticky modifiers and auto capitalization (at the beginning of a sentence). Even though the Pro¹ has a large keyboard, it feels more comfortable to me to have sticky modifiers (after all, it is still thumb-typing). Now currently the `Fn` modifier is not sticky in either case, so it wouldn't make a difference whether handled in the kernel or higher up, but I think that this might be something that Lineage or even upstream AOSP is willing to accept a patch for. After all, when even `Alt` is sticky, having `Fn` left out seems like an oversight, or at least something that should be toggleable at build time. If this would be done, the in-kernel mapping of `Fn` would prevent it from becoming a sticky modifier, or the kernel driver would end up emulating the behaviour from userspace (which still would be weird when an app disables the sticky modifiers and then `Fn` is left as the only stick one). To be fair, I also see the point of doing it in-kernel: Apps on Android can not only disable sticky modifiers (example: Termux), they can also choose to disable some modifiers at all (example: the built-in Terminal disables `Fn`). Especially with QWERTZ, having `Fn` disabled leaves one unable to input some (crucial) symbols. Having the `Fn` mapping done in the driver would work around this and present a full ANSI keyboard to every App (so if an App disables even more modifiers like Shift, it would be unusuable even with a full keyboard). I'd personally say the apps should be fixed, but it is possible that many more apps exhibit this behaviour. I suspect that many "remote desktop" type Apps will fall under this category as they will want to pass the modifiers through to the target (which probably doesn't understand the `Fn` modifier at all, or has a different behaviour for it). The only one I've tested so far is "KDE Connect" with its remote keyboard feature, which surprisingly does not try to pass through `Fn` but correctly applies it locally.
  6. Gigadoc2

    Factory Restore Tool

    It's not an intentional option... I don't really know how the SailfishOS porting process is supposed to work, but I have a Jolla and compared some of the things we found out in the chat with the Jolla; and to me it looks like you mostly take the userland from the Jolla, add changes and put that onto the new phone. Now, I don't know how familiar you are with desktop Linux (I have no idea if your interest is mainly Android or Linux in general), but if you are familiar: SailfishOS is very much like a desktop Linux distribution, amongst other things it is using systemd, udev and udisks2. Now it seems that dirty OEM hacks are not only a thing in Android, they seem to be in Sailfish too: Sailfish has modified the udev rules for udisks2 (in /lib/udev/rules.d/80-udisks2.rules), adding rules that automount all mountable partitions from SD cards and USB sticks (to be precise: they add a dependency for that device on an instanciated systemd service which starts after the user session is up (via a dependency) and calls udisksctl as user nemo to mount the specified device). Problem is, they just hardcoded a matching rule which only works for the Jolla itself (or similar phones): It matches every mmcblk device except mmclbk0 (internal storage on the Jolla), and every partition on every sd[a-z] device. To hide the internal partitions on the Jolla, they just hardcoded the same matching rule in the storage settings. What I probably don't need to tell you: The Pro1s storage appears to the kernel not as mmcblk0, but various sd* devices. So, the internal partitions not only show up in the storage UI, the system even tries to mount them all xD That, btw, is also the reason why Sailfish currently can't mount the SD on the pro1, it is instead recognized as internal storage. Now, here is where my knowledge about udev and udisks ends: On desktops, udisks is aware of which drives are internal and which are externally attached drives, but I don't know how exactly. Udisks is meant for users to mount or format their USB sticks and such without needing root rights, but then it does not allow them to do such to internal storage. Now the proper solution would be for Sailfish in general to use that facility and properly mark the internal storage. If that is also done with udev rules, there could be one rule file specific to the device, making it easy to port to different hardware. But I suppose that is something Jolla has to change, so for now the porters will have to do with somehow overwriting both the storage app and the udev rules :(
  7. Gigadoc2

    Factory Restore Tool

    Ok, so the restore-tool sends the idealte-signed (or is it qualcomm-signed?) firehose programmer to the phone, and then communicates with said programmer over USB to send it the stuff it has to flash (or receive whatever it reads), am I getting this right? So in theory, if one were to take the signed firehose from your tool it could be used with the Linaro tool or something similar? And I take it that you don't have the firehose source (and if you had you couldn't sign the resulting binary), but what with the code from cyngn? I suppose you are not at liberty to release the source of it? 😇
  8. Gigadoc2

    Factory Restore Tool

    Yass! Oh, that sounds very interesting! How much is your tool dependent on the NDA stuff F(x)tec gave you? Do you think it is possible to develop something like it as open source, and add reading capabilities to it? I mean, that sounds like a prime way to fully, completely, back up your device :D But apart from that, if you can read flash with EDL, doesn't that kind of defeat locked bootloaders? As in, now I can dump the data from the phone before I tamper with it to get the decryption key? Or is that completely mitigated by a part of the encryption key being stored in a secure element which is not dumped via EDL?
  9. Gigadoc2

    Factory Restore Tool

    It looks like QDL mode is EDL mode -- at least when I put my device into EDL mode it is listed as "QDL mode" in `lsusb`. As it seems the only tool we have for EDL flashing is the one from this thread, you can't really cherry-pick partitions to flash. However, the tool offers the "Base only" option. I have not tried that, but according to tdm's page here, "base only" will keep most of the "high-level" partitions intact, so it might leave SailfishOS mostly untouched. What you can't do in any case is checking which partitions are "corrupt", as far as I know neither EDL nor fastboot allow you to read data, it will only write it.
  10. Gigadoc2

    Factory Restore Tool

    I am afraid that this is exactly what you did 😞 Just yesterday I talked about this with the others in the Chat (not using SailfishOS myself, that's why I didnt find out sooner). It seems that Sailfishs logic what to hide in the UI, as well as their automount logic, is to some extent hardcoded to the hardware of the Jolla (or maybe the Xperia phones too). So all these unformatted partitions are indeed internal partitions of the Pro1... You may have deleted the bootloader, the modem firmware, or similar stuff... At this point, all you can do is to EDL flash, I am afraid 😞
  11. @EskeRahn: I know, that is why, if they have programmed the changes themselves, they may have the rights to open it :)
  12. @Waxberry: Did you (fxtec) program the stock launcher? If so, could you open-source it? That might allow users to improve it or install it on LineageOS and such.
  13. Why is that stored in persist in the first place? Has it something to do with the FDE of stock? Though you'd always unlock before using Fingerprint anyway?
  14. Gigadoc2

    ROM: Ungoogled Stock

    Thats... actually somewhat awesome. I mean, enrolling my own key would be better, but this way, I can prevent an "quick reflash" evil maid attack while still being able to run custom roms. Although, someone might still reflash via EDL without wiping data, defeating that. And, I don't know whether I want to risk not being able to fastboot flash anymore without wiping data first^^
  15. Gigadoc2

    ROM: Ungoogled Stock

    To my great surprise, I have to object here. I just re-locked the bootloader after flashing a self-singed LineageOS build, and it still boots. I even disabled OEM unlock... I don't really know whats happening here. This does not sound like what the android documentation says, and also not how other bootloaders behave. But I have a re-locked bootloader now that boots my LineageOS...
  • Create New...

Important Information