-
Notifications
You must be signed in to change notification settings - Fork 5
DebianTP3Planning
Some random notes/possible items to include in the next TP release.
Basic calls support is now implemented. Settings UI work to follow after TP3.
This involved:
- Audio routing - automatic based upon device state. Prioritising BT headset/audio jack headset then, open/closed state of device to pick where the call audio should go. Still some work on earpiece/microphone swapping on device orientation.
- Lock screen support - lock screen needs to become 'call' aware and should have the ability to answer/reject calls etc. Probably add clock/other info to lock screen at the same time. So far just letting the silver button answer calls has been added.
- Repowerd - needs to extend call support currently it looks to handle it a bit, basically it needs to keep the device fully powered whilst there is a call in progress, or an incoming one is noticed and we are ringing/vibrating/pulsing LED's etc. So far we've just added support for display of incoming call & ability to answer.
- Notifications - currently a new text message will launch a notification in lxqt land, I've not actually looked to see what component is responsible for this, but whatever it is its a candidate for handling incoming calls. Currently its 'Activity' buttons don't work, it would be nice if for example messaging/dialer could be opened from these popups.
- LEDs - gemian-leds has been updated to display flexible animations. The settings UI and a nice editor for the block of five animations is probably post TP3.
- It sounds like x27 folk have to change some settings in Android before SFOS can talk mobile things, I'm guessing that applies to Debian as well, can we have details of those changes so that we can make things work for Linux only folk too. This may not be the case, conflicting rumours, needs someone with a fresh device to report back.
Calls as above, but also enabling Stereo on the speakers and fixing the polarity of the hardware in software is planned.
Nice to haves - avoid glitchy audio (unknown cause), and fixing gappy audio when device is closed by fixing the module-droid-keepalive currently its not working.
Given that we have so many things that can be plugged into the USB port it seems that the sensible thing to do is to support modules, it sounds like its quite easy see Thread on OESF and Jürgen's Modular Howto we just need to decide on the best plan for packaging it. I think the last suggestion I heard was to package the kernel, modules and headers so that you can apt-get them together.
I did look into this, didn't get anywhere the module supporting kernel build didn't boot.
I've added a 'androidboot.bootpartition=boot2' to the kernel cmdline from the boot loader to indicate which partition the boot is active from. This will then allow the kernel upgrade to update the correct boot partition. However given the possibility of creating a device that cannot be booted from mistakes with this for the moment the kernel install just reports a suggested dd recipe and for those without the relevant boot loader displays a message to remind the user that they need to dd flash the kernel manually as we don't know which partition they are using for the current boot.
It seems we forgot to include the security repo for debian stable, so thats an easy fix. Also there is a security pull request on the gemian kernel repo for someone to review. We also need to regenerate the host keys for each device (as part of first boot tool?).
The device closes on its keyboard and with the keys partially depressed, generally some of them do fire on close/open or with a nudge/shake of the device when closed. The planet suggested solution to this is to disable the keyboard on frame buffer off state, and to turn off the screen with the lid switch. This generally leaked a possible keypress in the randomness of the timing gap between those occurrences. Also the on key is one of the ones that can be pressed causing the device to wake up and start taking key presses whilst its closed.
The latest kernel has this shorted so that the lid switch directly disables the keyboard, initial indications are that this is much better.
A first boot setup tool might be nice to allow easy configuration of for example locales/timezones.
Currently whilst the device is sleeping with wifi on there is a continuous cycle of the wifi being turned off and then on again, still looking for a fix for this it was suggested that connman-plugin-suspend-wmtwifi would help, but it appears not.
It would be nice to work out the random rebooting/freezing, which interestingly is much more reproducible on buster. Nikita suggested it might be related to a deadlock in our mishmash X+sleep environment, having watched this old video about how crazy X11 is I'm slightly more inclined to say maybe we just cut our losses and move with the times and go to Wayland, particularly as we want to be battery efficient. I'm assuming that we'd be able to take some of the work from sailfish/wlroots for that? And possibly work with them to get the external display stuff working too? (assuming they are planning on supporting that). Or move to fyne.io which is rumoured to be also targeting Wayland on Gemini also.
There has been no progress on this so I suspect this is now scheduled for post TP3.
The latest sailfish images have moved to using LVM, see SailfishLVM