[SUPPORT] Getting Clight to work on the Pinephone

[jclsn]

I am currently trying to get clight to run on the Pinephone, because there is not working solution for the backlight adjustment yet. I started out with zero configuration, but verbose turned on. It can detect the backlight values just fine and also finds a sensor, but then fails to capture it.

Here is the log

Clightd found, version: 5.4.
AC screen backlight curve: y = -0.024825 + 0.191641x + -0.008928x^2
BL
^
|        **
|      **  
|     *    
|    *     
|   *      
|  *       
|          
| *        
|*         
|          
*---------->BR
BATT screen backlight curve: y = -0.010629 + 0.153844x + -0.007284x^2
BL
^
|          
|          
|       ***
|     **   
|    *     
|   *      
|  *       
| *        
|          
|*         
*---------->BR
Set timeout of 30s 0ns on fd 15.
Failed to create org.freedesktop.ScreenSaver dbus interface: Unknown error -1
Monitoring requests to org.freedesktop.ScreenSaver name owner.
Disarmed timerfd on fd 39.
Not a laptop device. Killing UPower module.
Failed to retrieve AC state; fallback to ON_AC and OPEN lid.
Emitting 'AcState' property
idle_get_client(): Operation not permitted
Clightd idle error.
Failed to init. Killing module.
Set timeout of 0s 1ns on fd 26.
Emitting 'LidState' property
Set timeout of 30s 0ns on fd 26.
53.56 10.05 loaded from cache file.
idle_get_client(): Operation not permitted
Clightd idle error.
Failed to init. Killing module.
Loc distance: 53.56,10.05 -> 91.00,181.00 : 2449.69 km.
New location received: 53.56, 10.05.
Set timeout of 0s 1ns on fd 11.
Emitting 'Location' property
Next alarm due to: Sun Oct 17 17:49:00 2021
Set timeout of 18189s 0ns on fd 11.
Emitting 'Sunrise' property
Emitting 'Sunset' property
Emitting 'DayTime' property
set_temp(): Operation not permitted
Failed to set gamma temperature.
Set timeout of 0s 1ns on fd 12.
Sensor '/dev/iio:device1' is now available.
Resumed as a sensor is now available.
Emitting 'NextEvent' property
Emitting 'SensorAvail' property
capture_frames_brightness(): Operation not permitted
Set timeout of 600s 0ns on fd 12.
^CReceived 2. Leaving.
Latest location stored in cache file!

Do I have to add the user to some group maybe? It also says that it is killing uPower. Is that maybe the issue?

Checklist

• Implement an adaptive transition speed for cases when lighting conditions are switching rapidly (e.g. add a multiplier for the trans_timeout from 0.5 to 2 that is based in the difference of two measured values)
• Fix the IO errors when capturing from the ambient light sensor
• Don't reset the brightness after Plasma has dimmed the screen

[FedeDP]

Hi @coldspark29 !
I am so proud to hear that you're testing Clight on a pinephone!
Looking at the verbose log you provided, it seems that Clightd is always responding EPERM (indeed, not just backlight, but gamma and idle too!).
I am wondering what's causing the bug. Maybe Clightd is not running as root?
Or polkit/user session is not correctly set up? (the latter one looks the most probable culprit to me!)
To quickly test if it is a polkit issue, you can try:
busctl call org.clightd.clightd /org/clightd/clightd/Backlight org.clightd.clightd.Backlight GetAll "s" ""

Ie: if Getters are working, but Setters are not, it means that we have a polkit issue (clightd does not allow non active user sessions to call its Setter methods!)

[jclsn]

And I was looking at your code yesterday and thought that it is some pretty sophisticated C code in an almost objective style. I couldn't figure out how you query the sensors really. I always use a plain read() command on sensors in /dev. I also couldn't cat /dev/iio:device1. Are brightness sensors different? Or is it the industrial IO?

Anyway seems like I don't need to understand your code. It was indeed a polkit issue and clight works on the Pinephone. It needs some brightness curve settings though. The defaults are too dark.

And well there is no brightness control solution yet. I think clight would be a good choice as it already implements a good basis. I think a cellphone solution should be easier accessible though. clight-gui seems not to be supported on ARM architectures. Maybe we could come up with a perfect config file for the Pinephone.

I think clight has one drawback though. When it is activated and you manually set the brightness higher, the override doesn't last that long. So it gets dark again and this could become very annoying on phones. But this is just a suspection. I will tinker with it a lot now. I wonder how iPhones and modern Android phones handle manual settings. Maybe there is some kind of machine learning that remembers the user's preferences or the override lasts longer - maybe until the screen turns off again.

I think with some adjustments clight could become the standard app on mobile Linux phones. We will see :)

[jclsn]

Can you somehow increase the polling interval to make it react faster to ambient light changes?

I was also wondering how iPhones do their amazing brightness control. I was watching how the brightness bar was changing on the train and it was reacting instantly. Really amazing! I believe it must be an observer pattern that registers to the XNU kernel and gets notified upon changes. Or it is a hardware controlled solution with its own small microcontroller. I think if clight did poll every few milliseconds, it would consume a lot of power, wouldn't it? For laptops such a dynamic brightness control is rarely needed, as they are mostly stationary, but for phones I think we would need to increase the polling interval a bit.

[nullobsi]

clight-gui seems not to be supported on ARM architectures.

i dont see why it shouldn't be--but the interface could hardly be called touch friendly 😆

but since I already have C++ models, perhaps a QML/QT Quick app is in order :)

[FedeDP]

And I was looking at your code yesterday and thought that it is some pretty sophisticated C code in an almost objective style

Yep, i use my own libmodule library to create an actor like application.
I think that architecture helps Clight be much easier to maintain and develop ;)

I also couldn't cat /dev/iio:device1. Are brightness sensors different? Or is it the industrial IO?

You should look for it in Clightd: https://github.com/FedeDP/Clightd/blob/master/src/modules/sensors/als.c.
It uses the iio subsystem and libudev to find a matching device.

Anyway seems like I don't need to understand your code. It was indeed a polkit issue and clight works on the Pinephone. It needs some brightness curve settings though. The defaults are too dark.

Yaaaayyyyy!! That's great!

Maybe we could come up with a perfect config file for the Pinephone.

That would be fine, indeed; but i guess having a small gui would be great too!
I am not much into GUI though, hopefully someone in the pinephone community can step up :)

When it is activated and you manually set the brightness higher, the override doesn't last that long.

You mean that on next sensor polling, a different value is set?
This could be easily fixed by enabling the NoAutoCalib feature on Clight when user touches the backlight; then, if user wishes to go back to "auto", "NoAutoCalib" should be set to false, thus allowing clight to restart its calibration. It's super simple yet effective!

Note that Clight has quite a big dbus API that allows user/application to fully manage it! (you can even update the ambient brightness to backlight curve on the fly!)

I think with some adjustments clight could become the standard app on mobile Linux phones. We will see :)

You know, i'd be thrilled! I am looking forward for it; unfortunately, i do not own a pinephone, thus i am not able to help.
Anyway, feel free to reach me for any issue/question!

Finally, if you are available, we could add a wiki page on Clight for Pinephone support! I can give you repo access if you are willing to!

[FedeDP]

PS: we can keep this open to further discuss!

[FedeDP]

Can you somehow increase the polling interval to make it react faster to ambient light changes?

Yes, see {ac,batt}_timeouts in conf file: https://github.com/FedeDP/Clight/blob/master/Extra/clight.conf#L71

[FedeDP]

@coldspark29

I think if clight did poll every few milliseconds, it would consume a lot of power, wouldn't it?

I don't think polling the ambient light sensor eg: every second, would be too much expensive; but obviously i never tried!

[FedeDP]

It also says that it is killing uPower. Is that maybe the issue?

Nope, but that's actually a feature. In the latest versions Clight kills UPower support if it is not on a laptop device (i never thought about the pinephone!); this can be easily reverted to support ac/battery state too!

[jclsn]

Okay I think I found some values that work. It can actually be done. I have an idea for the changing of the brightness. I think we would need a non-linear change of brightness. Atm you can just set a timeout and it will linearly increase or reduces the brightness, but on sudden changes, the brightness should change suddenly and else just slowly to not be too distracting.

On my laptop I have a trans step of 0.001 so I barely ever realize that it is doing something. On a phone you should also not realize it, but as the ambient lighting might change more dynamically, the transitions steps (or the transition speed with the same smooth steps) should also adjust dynamically. I think this would be a killer feature!

[jclsn]

Hmm getting an IO error now on capturing the frames. I already tried restarting. Did I maybe set the timeout too high with 1 second? How can I debug this? It doesn't seem to be related to the config file. Hopefully I didn't break anything :/

Set timeout of 30s 0ns on fd 11.
Not a laptop device. Killing UPower module.
Failed to retrieve AC state; fallback to ON_AC and OPEN lid.
Emitting 'AcState' property
Set timeout of 0s 1ns on fd 20.
Emitting 'LidState' property
Set timeout of 30s 0ns on fd 20.
53.61 9.93 loaded from cache file.
Loc distance: 53.61,9.93 -> 91.00,181.00 : 2445.85 km.
New location received: 53.61, 9.93.
Set timeout of 0s 1ns on fd 21.
Emitting 'Location' property
Currently inside an event.
Next alarm due to: Mon Oct 18 18:47:00 2021
Set timeout of 1513s 0ns on fd 21.
Set timeout of 0s 1ns on fd 27.
Sensor '/dev/iio:device1' is now available.
Resumed as a sensor is now available.
Emitting 'Sunrise' property
Emitting 'Sunset' property
capture_frames_brightness(): Input/output error
Set timeout of 1s 0ns on fd 27.
Emitting 'DayTime' property
Emitting 'NextEvent' property
Emitting 'InEvent' property
Emitting 'SensorAvail' property
capture_frames_brightness(): Input/output error
Set timeout of 1s 0ns on fd 27.
capture_frames_brightness(): Input/output error
Set timeout of 1s 0ns on fd 27.
capture_frames_brightness(): Input/output error
Set timeout of 1s 0ns on fd 27.
capture_frames_brightness(): Input/output error

Guess this will need some more work, but thank you for the support :)

[jclsn]

but since I already have C++ models, perhaps a QML/QT Quick app is in order :)

@nullobsi Great to see that you are motivated as well. :) I think for the start it would be good to have a control widget. In the end it would be nice to have it implemented in the various desktop environments, but that will take a long time anyway.

I would also want to see first how this is received by the others. I am not sure if the devs of the desktop environments are already working on something, but I think this code has come already so far, that it just needs some slight modifications to also work for phones.

[FedeDP]

Did I maybe set the timeout too high with 1 second?

It could be, maybe the ALS device does not allow for that frequent pings? That's weird though!

I think for the start it would be good to have a control widget.

IMO i think a plasma5 panel applet would be best!

@coldspark29 Can you go on testing and then writing here a checklist of things to do, keeping it updated? I am very interested in giving pinephone the best clight experience ;)
Thank you very much both!
We will make it!

[FedeDP]

On my laptop I have a trans step of 0.001 so I barely ever realize that it is doing something. On a phone you should also not realize it, but as the ambient lighting might change more dynamically, the transitions steps (or the transition speed with the same smooth steps) should also adjust dynamically. I think this would be a killer feature!

This is a nice feature; let me recap: you want a transition time that is constant, ie: going from 0.30 to 0.25 would take the same time as going from 1.0 to 0.2?
I think it can easily added.
Please, add this feature request to the aforementioned checklist!
Thank you very much!

[jclsn]

Can you go on testing and then writing here a checklist of things to do, keeping it updated?

Sure, I can do that. :)

This is a nice feature; let me recap: you want a transition time that is constant, ie: going from 0.30 to 0.25 would take the same time as going from 1.0 to 0.2?

Yes, pretty much. I just verified this behavior on the iPhone. When you hold it in front of a lamp and then put your finger on the sensor, it goes from 100% brightness to 10 % brightness in an instant after like three seconds. For getting brighter is does this a little more slowly but basically the same behavior. Apart from that I have found quite some good settings now. They just don't work always realiably unfortunately, but it could be that there are some issues with the OS I have. I already asked in the Pinephone group. We will see who is interested in helping.

[jclsn]

I will post the optimal settings here and will update them if I find better ones. I am always open for improvements

verbose = true;

backlight:
{
    trans_step = 0.0005;
    trans_timeout = 2;
    ac_timeouts = [ 1, 1, 1 ];
    batt_timeouts = [ 1, 1, 1 ];
    # no_auto_calibration = true;
};

sensor:
{
    ac_regression_points = [ 0.1, 0.4, 0.5, 0.86, 0.88, 0.9, 0.92, 0.94, 0.96, 0.98, 1.0 ];
    batt_regression_points = [ 0.1, 0.4, 0.5, 0.86, 0.88, 0.9, 0.92, 0.94, 0.96, 0.98, 1.0 ];
};

keyboard:
{
    disabled = true;
};

gamma:
{
    disabled = false;
};

dimmer:
{
    disabled = true;
};

dpms:
{
    disabled = true;
}

[FedeDP]

Btw i find really stunning that we are actually talking about a phone! I mean, with geoclue, upower whatever!
It's incredible!

[jclsn]

Yeah, it will be pretty amazing. They have just announced an upgraded version with a faster processor a few days ago, that will have the potential to be usable as daily phone and fully-fledged PC in your pocket.

[FedeDP]

It's crazy! I saw that too, fingers crossed for it to be a success!

[jclsn]

So regarding the IO errors: They only seem to occur after killing clight and starting it manually. What is the proper way to stop clight and start it for debugging? Or maybe they just occur occasionally which is weird. This should definitely be fixed.

I was also thinking about the new adaptive trans_timeout feature yesterday. There may be cases where this is unwanted, e.g. when flashes from another camera or the lights of a passing hit the sensor for an instant. So there should be a certain delay of a few seconds. So if a certain threshold of light difference is crossed AND that state persists for more than 3-5 seconds, adjust the brightness instantly.

EDIT: Actually I just figured that setting the ac and batt timeouts to 3 seconds accomplishes this already. It also makes the transitions a bit smoother and I think they are still fast enough. Maybe we don't need this new feature at all. I will update the suggested config file.

[jclsn]

Really weird, the IO errors don't really follow a pattern. Maybe the hardware is broken

[FedeDP]

Clightd returns EIO when no capture succedeed (ie: none of clight conf.num_captures returned a value !=0).
Try to check dmesg if there is any message about the iio device!
Clightd does not much more than using libudev to read the sensor value btw!

[FedeDP]

Latest Clight allows back UPower module to run on Pinephone too :) (ie: on all devices, not laptops only!)

[jclsn]

That was a now fixed bug!
Care to try again? Thank you!

Ah no, this did not improve things. Actually even the settings with 1 second from before don't work anymore. The brightness slider is just shuffling back and forth. The brightness is not really decreasing when I cover the sensor with my hand.

[jclsn]

EDT: i now understand what you mean, sorry. In that case yes, you have to use clight dimmer instead of the system one. I cannot think of a better way to handle it, will look into that anyway!

I think we would need some sort of IPC with Plasma here, but that would get messy I think.

[FedeDP]

Ah no, this did not improve things. Actually even the settings with 1 second from before don't work anymore. The brightness slider is just shuffling back and forth. The brightness is not really decreasing when I cover the sensor with my hand.

That is weird, when timeouts_in_ms is disabled it should behave like before! :(

I think we would need some sort of IPC with Plasma here, but that would get messy I think.

Indeed, systemd logind exposes an IdleHint property, i need to check whether plasma is using it and add support for it in clight ;)

[FedeDP]

Indeed, systemd logind exposes an IdleHint property, i need to check whether plasma is using it and add support for it in clight ;)

I added support for IdleHint in Clight: clight will hook IdleHint to manage its value updates: when it is true, clight will manage a dimming state, otherwise it will leave dimming state.
Moreover Clight will now properly call SetIdleHint on logind when it dims/dpms the display.

Note that i don't yet know if kde sets the IdleHint property when it dims the screen; moreover, even if clight correctly handles the logind property, it still tries to set its dimmed backlight level in any case.
There is room for improvements here i guess.
In my opinion, the best option is to let clight manage dimmer too, and disable the builtin feature in plasma.

FInally, timeouts_in_ms was wrongly placed under KEYBOARD settings; it is now fixed and moved under BACKLIGHT settings.

[jclsn]

Will test it later. Thanks :)

[jclsn]

That is weird, when timeouts_in_ms is disabled it should behave like before! :(

It is fixed now :) Unfortunately settings the timeout that low doesn't have the desired effect. Instead of making it smoother it pauses every x ms. I already tried setting the transition timeout to 0, but that doesn't seem to have the effects of no timeout.

[FedeDP]

What about a couple of seconds {ac,batt} timeouts?
I mean, my android phone reacts to ambient light i'd say with a 1/2s delay; it does not seem to react in real time.

Are you able to record some backlight transitions with various different clight configs?
That would help me think of a good solution :)
Thanks!

[jclsn]

I don't have anything against a timeout of two minute, but the behavior was worse when I tried. I can't test the rest at the moment. The Plasma Mobile shell is broken atm and I have no time to attend to it, because I am currently moving. We will have to delay this till next month.

[FedeDP]

I don't have anything against a timeout of two minute, but the behavior was worse when I tried. I can't test the rest at the moment

You mean 2seconds, right? :D
Btw you have already been super helpful, thank you very much!

We will have to delay this till next month.

No problem :) I would've released next version with good support for pinephone, but i guess we can wait. We can always wait!

[jclsn]

Yeah two seconds... Last thing I remember was that the screen dimming of Plasma was not taken in account, so whatever you tried there did not work. That is the most necessary fix.

[FedeDP]

Btw is this:

Make it possible to set the ac_timeout and batt_timeout to ms

still relevant? I mean, if that does behave bad, i can even drop the feature altogether :)
I don't like having an option that could possible break non-ALS users, if a 1 second timeout is already fine.

[jclsn]

Well, the issue is not the capture timeout, but the pause of adjustment during the capturing. This should be made smoother. But to answer your question, I think that one second is good enough. So you can remove it:

[FedeDP]

In latest master (1d5ede6)

Don't reset the brightness after Plasma has dimmed the screen Kim

should be fixed. Basically, if DIMMER mod is disabled, DISPLAY hooks onto logind IdleHint property and manages that as (un)dimmed message, without touching backlight though (as DIMMER module is disabled).

[jclsn]

Sounds great. Will test it when I find the time!

[FedeDP]

Hi again!
I am looking to fix the remaining issue; was still wondering if a "fixed_transition_duration" would work fine.
Ie: a milliseconds value that is used as a fixed backlight transition duration. I think that is the right solution; moreover I see lots of use cases for it beside pinephone (i might use it myself too on my laptop!).

IMO the proposed multiplier solution is way too hard to explain and understand, and the outcome would be pretty similar to a fixed transition duration indeed. Am I wrong?

Thanks for your valuable input anyway, i really appreciate that!

EDIT: as i'm willing to release a Clight/Clightd upgrade for xmas, it would be great to offer Pinephone support fully working! With a wiki page, with a proposed config file, yours (thank you!), and may be also having a small showcase video of Clight running on it ;)
Obviously, if you are too busy with real life, that's not a problem! IRL business is, well, more important! :)

[FedeDP]

In latest master, i implemented a trans_fixed option for both BACKLIGHT and DIMMER, that allow users to set a fixed duration for the smooth transitions, given a 1% backlight steps.
Indeed, it feels so damn smooth (on my laptop at least) that i'm thinking about enabling it by default! What is blocking me is that it would break existing configurations, because enabling the trans_fixed will disable other trans_step and trans_timeout options.

[jclsn]

Hi, it's great that you are making more progress. I can't really test it out atm. I am way too busy with renovating my flat and frankly quite overworked. I am very interested though and will test it when I have the time.

[FedeDP]

Let me make it clear once more: your support is highly appreciated, really!
Thank you very much!

[jclsn]

So I just tested again. The issue that clight gets in the way of Plasma's dimming is not solved unfortunately. Have to uncheck it again. This btw also happens on my ThinkPad, so I guess you can test it on yourself using my clight.conf

Regarding the trans_timeout, I don't see a difference really. Maybe I haven't configured it right? I am still experiencing stops while it is transitioning.

[FedeDP]

Hi!
First of all, happy new year! :)

The issue that clight gets in the way of Plasma's dimming is not solved unfortunately

I guess Plasma is not setting the IdleHint logind property then :(

Regarding the trans_timeout, I don't see a difference really. Maybe I haven't configured it right? I am still experiencing stops while it is transitioning.

Mmh you mean the trans_fixed config? If affirmative, and you are still seeing a not-so-smooth transition, most probably the pinephone is not supporting a quick backlight refresh rate (eg: external monitors most of the time behave much worse than internal laptop panels).

[jclsn]

Happy new year as well! :)

Well maybe I configured it wrong. Is it a boolean or do I use it instead of the normal trans_timout?

Is there another possibility regarding the Plasma backlight dimming?

[FedeDP]

Well maybe I configured it wrong. Is it a boolean or do I use it instead of the normal trans_timout?

It is a milliseconds duration; it will be the total transition duration!

Is there another possibility regarding the Plasma backlight dimming?

I think that the best thing would be that Plasma actually supports IdleHint. You can see that Clight supports it good enough yourself:

• start Clight in verbose mode without dimmer enabled: clight --no-dimmer --verbose
• tail Clight log
• on another terminal, set the systemd logind idlehint: busctl call org.freedesktop.login1 /org/freedesktop/login1/session/auto org.freedesktop.login1.Session SetIdleHint "b" true
  You will see

Entering dimmed state...
Pausing BACKLIGHT: DISPLAY
Pausing SCREEN: DISPLAY
Emitting 'DisplayState' property

printed on Clight log.

(btw thank you! While re-testing this, i found a small bug that i promptly fixed :D )

I can't see any other solution that is DE agnostic. Indeed, it seems weird that Plasma does not set the IdleHint flag already!

[FedeDP]

@coldspark29 i did some research: gnome is indeed setting the IdleHint property in its session manager: https://gitlab.gnome.org/GNOME/gnome-session/-/blob/main/gnome-session/gsm-systemd.c#L560.

I opened an issue on kde bug tracker: https://bugs.kde.org/show_bug.cgi?id=448942

[jclsn]

Hopefully they will do something about it :) Atm I have clight disabled because of this. Like this it just produces more issues than it solves. I also think that you should probably get a phone to test it yourself.

[FedeDP]

Hi! Can't you disable dimming from KDE and rely only upon clight? I don't remember if there were any issues with that!

[jclsn]

Yes, but then it is not dimming at all. I still mainly use my iPhone anyway. The Pinephone is just not ready in many respects, that is why I still hesitate to buy the Pinephone Pro. I think getting clight to behave well on a phone will require a lot of testing under different lighting conditions. The requirements for a phone are just a bit different. That is why I believe that if you want to make clight phone-compatible, it would probably be best to have your own unit to see for yourself. So far only Ubuntu Touch has its own backlight control. I have no idea if an external service for this will be accepted by the OS developers anyway and if our efforts here are really worth it.

[FedeDP]

Yes, but then it is not dimming at all.

Interesting; most probably Clightd is not catching "idle" events (because it does not support touch events; that's weird because it looks in /dev/input/* though).

That is why I believe that if you want to make clight phone-compatible, it would probably be best to have your own unit to see for yourself

I agree, but i won't spend my money on something that i won't use daily; i am following Pinephone pro and linux on smartphones in general, and as soon as they are "consumer" ready (ie: i can use them daily without missing much functionalities) i will surely buy one of them.
For now, i will just wait for some help by the community; oh and btw you are in no way obliged to help me :) you already did it a lot!
I'll just keep this issue open hoping for more feedbacks! ;)

[jclsn]

Interesting; most probably Clightd is not catching "idle" events (because it does not support touch events; that's weird because it looks in /dev/input/* though).

Guess you misunderstood that. I think the system's dimming feature is useful. There was also an issue that you couldn't turn it back on once deactivated. So I just keep it on for testing purposes. And don't get me wrong. I will test this further when I feel like having a look at the phone. I just had it back in my hands after two months of being very busy. There was a major performance improvement, but looking at the phone more often than once a month is really not worth it, if you are not actively developing. I just think that we shouldn't duplicate efforts. There will be some brightness control at some point by KDE. They are a big community and good at implementing sophisticated features. You would probably have to change a lot to get clight in that direction and in the end it will not integrate into Plasma neatly. So we shouldn't invest too much effort in this if no one is going to use it in the end.

…

On Jan. 23 2022, at 12:31 pm, Federico Di Pierro ***@***.***> wrote: > Yes, but then it is not dimming at all. Interesting; most probably Clightd is not catching "idle" events (because it does not support touch events; that's weird because it looks in /dev/input/* though). > That is why I believe that if you want to make clight phone-compatible, it would probably be best to have your own unit to see for yourself I agree, but i won't spend my money on something that i won't use daily; i am following Pinephone pro and linux on smartphones in general, and as soon as they are "consumer" ready (ie: i can use them daily without missing much functionalities) i will surely buy one of them. For now, i will just wait for some help by the community; oh and btw you are in no way obliged to help me :) you already did it a lot! I'll just keep this issue open hoping for more feedbacks! ;) — Reply to this email directly, view it on GitHub (#233 (comment)), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AEW47N63KDCARFOK2G6ETYLUXPRIPANCNFSM5GEV2CDA). You are receiving this because you were mentioned.