[Samsung Galaxy S8 Guides, News, & Discussion] karatekid430:
I have always found Bluetooth to be less reliable - with my K810 and Surface Pro 1, it would take a random amount of time [5, 30] seconds at boot to pair - frustrating. It seems like the Marvell controllers that Microsoft use are poor - although they have improved over their lifetime.

When it works, my maxed out Dell convertible 9365 works well, but occasionally the Bluetooth suddenly dies. Much less frequently after the driver update, mind you.

Still cannot beat the reliability of a USB receiver - and a USB receiver can work in BIOS. If you dual-boot, you can make both operating systems use the same pairing key for Bluetooth, but it is fiddly.

The thing about USB receivers is that you can attach them to a docking station, and they disconnect when you remove the device. With Bluetooth, you walk into another room and realise that your phone is still connected to the Bluetooth keyboard.

Hence Samsung need to allow the option to disable on a per-device basis peripherals when not connected to the DeX Station.

I don't like Intel at all as a company, but for Thunderbolt, Ethernet and wireless controllers, I prefer them. For example, Intel drivers are your best hope for doing NIC teaming in non-server Windows.

Notable is that in the kernel of the S8, I noticed that defined were the vendor and device IDs of a Samsung USB cellular modem. With the Tab S2 onward (might have been earlier ones, but I did not look because it was before USB-C sparked my interest) and the S8 onward, Samsung have enabled 3rd-party Ethernet (as all in this thread will know). The next thing would be to allow USB wireless adapters and Bluetooth. That would allow for attaching a wireless card with a 24dB directional antenna and pick the university Wi-Fi up way off campus. Granted, you could just use an Odroid C2 powered off a battery, controlling the wireless card and SSID authentication, passing the data through wired Ethernet to the Samsung device. Either use SSH to control it, or install a touch screen module on it and make a GUI.

It would be good if they allowed third party drivers to be loaded, but Samsung would have to have some sort of signing process like Microsoft WHQL, to avoid people using it to root their devices.

Tangent aside, it would be nice if the Galaxy could take the USB Bluetooth module - perhaps by chance, a chip of a different vendor might play nicer with your particular device. Does the cheap keyboard do this with other devices? Do you have a laptop or desktop with Bluetooth? If not, you can obtain the USB sticks that should work with anything except Android. Although as a root user, you might be able to hack it together.

About the kernel, who should I ask? Who knows a lot about the kernel and might be interested in this stuff? The latest posts in the Jesse S8 kernel are people wondering if the kernel is dead (I assume they mean that Jesec has lost interest). And he did say that compilation assistance would be ignored, although my issue is only related to compilation - I can compile it fine, but it is making the damn thing boot that is the issue.

I am just concerned - the instructions I just gave 100% work, but only if you have flashed the Jesse kernel zip previously, and hence have the patched /system partition. I thought that was required due to the bump in kernel version of the Jesse kernel, but it seems that it might be for some other reason.

Starting to think that learning kernel development might be a good career move, to get closer to the intersection between software and hardware architecture. But it's a very big pond for a little fish to adapt to. Problem is that my university UWA seems to be diverging away from real programming, and more into project management and software processes. So I am stuck as to from where to amass significant amounts of information, aside from brute-forcing it out on my own. I do know Dr Chris McDonald at UWA is probably a wealth of information on this matter, but I feel like we don't fully see eye to eye despite having many similarities. It didn't help that I was forced to use Linux / Mac in an early UG unit of his, before I was accustomed to Linux. If anybody can suggest where I should be looking, that would be appreciated. The more I learn, the more likely I am to be able to solve more problems like this for XDA.

---------- Post added at 03:16 AM ---------- Previous post was at 03:05 AM ----------

Oh, forgot to mention, as for the encryption, I am happy to factory reset every time I have to update (it isn't my main phone, anyway). I would only encrypt once I had it modified to a state that I was happy to keep for a while. A friend tells me that anything custom does not really work with encryption - and not just Nougat. Which does not wholly make sense, because a fully custom ROM is just like an official ROM but from another company. It might be something to do with the way that (afaik) partial encryption keys are kept in a secure zone of the SoC, so that if the encrypted data is taken off the device, the password alone is insufficient to derive the filesystem encryption key. Perhaps it is tricky, and only the manufacturer can do it reliably. Personally I would just find some long chain of operations on the password that involve a variety of different cryptographic hashes and operations to produce the encryption key, in such a way that it will be theoretically resistant to quantum computing algorithms, and will take too long to brute-force for the next several decades. A security expert might see flaws with my reasoning, but still, I prefer simplicity. After all, I read something where they could use exploits to get into the secure zone (it runs its own miniature kernel according to the article) and exploit the secure zone to achieve kernel mode escalation, and dump the device-binding key, allowing for the password to be brute-forced.