Reply
Thread Tools
Posts: 254 | Thanked: 509 times | Joined on Nov 2011 @ Canada
#41
So just to be clear, there is nothing at a hardware level tying engine3 to the hardware leds?

A first step towards freeing up engine3 could be to rewrite MCE to just turn on the lights rather than dimming them with a pattern and then add the ability of engine3 to be used by the notification led instead. One issue I guess is the format of the mce.ini/pattern itself. It's either upper or lower case depending on what engine you want controlling what color... Which is only two options. How to designate a third without breaking compatibility? Or just hard code engine3 to control Blue only?
 

The Following 2 Users Say Thank You to shawnjefferson For This Useful Post:
joerg_rw's Avatar
Posts: 2,222 | Thanked: 12,651 times | Joined on Mar 2010 @ SOL 3
#42
Originally Posted by shawnjefferson View Post
So just to be clear, there is nothing at a hardware level tying engine3 to the hardware leds?

A first step towards freeing up engine3 could be to rewrite MCE to just turn on the lights rather than dimming them with a pattern and then add the ability of engine3 to be used by the notification led instead. One issue I guess is the format of the mce.ini/pattern itself. It's either upper or lower case depending on what engine you want controlling what color... Which is only two options. How to designate a third without breaking compatibility? Or just hard code engine3 to control Blue only?
Yes, nothing in hardware.

For a definition of extensible format see: http://wiki.maemo.org/LED_patterns#Pattern_Format (did that quite some time ago already . though now I start to wonder if I could come up with something old MCE would work with as well)
Though the LP5523 chip has 3 engines meant to control R, G, and B, the mce program exlusively uses engine3 for kbd backlight and so doesn't support pattern definitions for engine3. mce is closed source and thus this can't be fixed in any reasonable way. If mce were open, an alternative compatible format was possible:
Code:
PatternName=Priority;ScreenOn;Timeout;LEDsToMap;Engine1Pattern;Engine2Pattern;Engine3Pattern
where LEDsToMap was something like "001230000" to map the particular LED to either none, or Engine1..3 respectively.
We could also fix mce to allow pattern definitions of arbitrary length up to the max RAM available, which is 96 commands with all RAM allocated to one engine - this would need a patch to support doing this in lp5523.ko driver as well.
Note that an improved MCE could distinguish between RgB and 001230000 format and support both

/j
__________________
Maemo Community Council member [2012-10, 2013-05, 2013-11, 2014-06 terms]
Hildon Foundation Council inaugural member.
MCe.V. foundation member

EX Hildon Foundation approved
Maemo Administration Coordinator (stepped down due to bullying 2014-04-05)
aka "techstaff" - the guys who keep your infra running - Devotion to Duty http://xkcd.com/705/

IRC(freenode): DocScrutinizer*
First USB hostmode fanatic, father of H-E-N

Last edited by joerg_rw; 2014-01-25 at 21:05.
 

The Following 3 Users Say Thank You to joerg_rw For This Useful Post:
Posts: 254 | Thanked: 509 times | Joined on Nov 2011 @ Canada
#43
I have MCE compiled on my device that doesn't use engine3 for the keyboard LEDs at all, it simply turns on the keypad backlight with the desired brightness and then turns it right off when required with no delay or fade. The fadetime from the MCE.ini is ignored.

Originally Posted by joerg_rw View Post
Note that an improved MCE could distinguish between RgB and 001230000 format and support both
It should be easy enough to distinguish between an "old" pattern and a new one. If the field starts with a digit, it's a new three-engine pattern, if not, it's an old 2 engine pattern.

My understanding is that each LED can only be assigned to one engine (there's a check in MCE led.c for this that ignores a pattern that tries to assign a led to two engines), so wouldn't a three digit format work? First digit is Red LED, second is Green, third is Blue.

For example:

112 = Red + Green on engine1, Blue on Engine 3
111 = All on Engine 1
123 = Red on 1, Green on 2, Blue on 3.

then tack on another pattern to the end of the ini string like has already been suggested for the engine3 pattern.

Last edited by shawnjefferson; 2014-01-30 at 07:38.
 

The Following 2 Users Say Thank You to shawnjefferson For This Useful Post:
joerg_rw's Avatar
Posts: 2,222 | Thanked: 12,651 times | Joined on Mar 2010 @ SOL 3
#44
Originally Posted by shawnjefferson View Post
My understanding is that each LED can only be assigned to one engine (there's a check in MCE led.c for this that ignores a pattern that tries to assign a led to two engines), so wouldn't a three digit format work? First digit is Red LED, second is Green, third is Blue.

For example:

112 = Red + Green on engine1, Blue on Engine 32
111 = All on Engine 1
123 = Red on 1, Green on 2, Blue on 3.

then tack on another pattern to the end of the ini string like has already been suggested for the engine3 pattern.
Yes, all absolutely in line with what I thought, I can live without fading effect for kbd *). Just we have 9 leds total, 3 in indicator LED (RGB) plus 6 LEDs in kbd. thus a 9-digit string for new mux-pattern, one digit for each LED. To simplify we may allow the following shorthand: format is 9 digits 0..3 : RGB123456 with (R,G,B) = indicator LED and (1..6) = kbd-LED1..6, and any mux string of less than 9 digits is extended to 9 by appending the required amount of "0". "231" means "231000000" which says R=engine2 G=engine3 B=engine1 and all kbd not assigned to any engine. Note that "000" is also a valid pattern, meaning that none of indicator LEDs (and implicitly by extension none of kbd-LEDs) is assigned to any engine.

To allow for backward compatibility, new mce shall search for a section "[LEDPatternLystiRX51-new-mce]" first, and then search "[LEDPatternLystiRX51]" if the required key isn't found in yet. IOW mce scans both "[LEDPatternLystiRX51-new-mce]" and "[LEDPatternLystiRX51]" in this sequence, and any definition of a key can't get overridden by a later identical definition.
Thus you can keep new syntax patterns in "[LEDPatternLystiRX51-new-mce]" and allow the file to still work with old mce as well. Or you use new syntax in "[LEDPatternLystiRX51]" and forget about old mce

*)
you nevertheless might consider defining a constant key name for/like "PatternKbdOn" and "PatternKbdOff" which get called by mce whenever kbd backlight status changes accordingly.

sample mce.ini (also see attachment)
Code:
[LED]
# List of patterns for the LED functionality
# 
# A list of all pattern names that should be configured
LEDPatterns=PatternVboost;PatternError;PatternDeviceOn;PatternPowerOn;PatternPowerOff;PatternCommunicationCall;PatternCommunicationIM;PatternCommunicationSMS;PatternCommunicationEmail;PatternCommonNotification;PatternWebcamActive;PatternBatteryCharging;PatternBatteryFull;PatternDeviceSoftOff;PatternInhibit

[LEDPatternLystiRX51]
PatternError=0;5;0;r;9d8040005000500040ff0b8c5c000000;9d800000
PatternDeviceOn=254;0;0;gb;9d80400006c509ad23650000;9d800000
PatternDeviceSoftOff=253;0;0;rg;9d804000423f433f7f100000;9d800000
PatternPowerOn=9;3;0;rgb;9d80400042ff02ffc000;9d800000
PatternPowerOff=10;3;0;rgb;9d80400001ff43ff7f007f00c000;9d800000
PatternCommunicationCall=30;1;0;b;9d80400002ff03ff02ff03ff71080000;9d800000
PatternCommunicationIM=30;1;0;b;9d80400002ff03ff02ff03ff71080000;9d800000
PatternCommunicationSMS=30;1;0;b;9d80400002ff03ff02ff03ff71080000;9d800000
PatternCommunicationEmail=30;1;0;b;9d80400002ff03ff02ff03ff71080000;9d800000
PatternCommonNotification=30;1;0;b;9d80400002ff03ff02ff03ff71080000;9d800000
PatternWebcamActive=20;1;0;r;9d80400004ffc0000000;9d800000
PatternBatteryCharging=50;4;0;rg;9d80400020de0dc57f007f0042000000;9d800000
PatternBatteryFull=40;4;0;g;9d80407f0000;9d800000

###[[new]]
[LEDPatternLystiRX51-new-mce]
# Section for new MCE. Stock MCE will ignore this section.
# New pattern syntax goes here to keep it out of the classical [LEDPatternLystiRX51] section for backward compatibility, though that's not mandatory.
# Any pattern in this section overrides a pattern with same name in [LEDPatternLystiRX51] section.
# Pattern names in here need to get declared in "[LED] LEDPatterns=..." just like the classical patterns in [LEDPatternLystiRX51]
###[[end-new]]
#
# Priority (0 - highest, 255 - lowest)
# ScreenOn - 0 only show pattern when the display is off
#            1 show pattern even when the display is on
#            2 only show pattern when the display is off, including acting dead
#            3 show pattern even when the display is on, including acting dead
#            4 only show pattern if the display is off, or if in acting dead
#            5 always show pattern, even if LED disabled
#
###[[new]]
# Timeout in seconds before pattern is disabled, 0 for infinite - [[++]] decimals allowed: "0.5" = 500ms 
# LED mux to map each LED to either none (0) or to Engine 1/Engine 2/Engine3
#        1 to 9 digits, short strings get filled to length 9 by appending zeroes
#        Meaning of each of the 9 positions is: 
#        R G B kbd1 kbd2 kbd3 kbd4 kbd5 kbd6
#
#        Example:
#            "031010020" maps the red LED to none, 
#                               green LED to engine 3,
#                               blue LED to engine 1,
#                               kbd backlight LED1, 3, 4, 6 to none,
#                               kbd LED2 to engine 1, and kbd LED5 to engine 2
#        Do not mix the new mux syntax consisting of digits "0".."3" with the old "rGB" syntax in one pattern!
# Engine 1 pattern in Lysti format (31 commands at most) - one step used internally to store muxmap used by 9d80 cmd  
# Engine 2 pattern in Lysti format (32 commands at most)
# Engine 3 pattern in Lysti format (32 commands at most)
#        empty patters allowed (;;), such empty patterns shall not change the state of the according machine.
#        A pattern of "-" changes the meaning of "0" in LED mux: an LED previously assigned to this engine will not get reassigned to none when "0" in LED mux 

#PatternVboost=60;5;0;rB;9d80401a480040d948000000;9d80400b2c900000
PatternVboost=60;5;0;102;9d80401a480040d948000000;9d80400b2c900000
# Kbd fade in 250ms; engine3; patterns for engine1/2 empty+no-remux, thus any pattern running in engine1/2 and using RGB will continue  
PatternKbdOn=11;5;0.251;000333333;-;-;9d80400003ffc000
Note: depending on the way LED-Pattern-Editor and other programs that change mce.ini work, it might be necessary to insert [LEDPatternLystiRX51-new-mce] before [LEDPatternLystiRX51], so that [Vibrator] section follows the original [LEDPatternLystiRX51]



A note from my local mce.ini about the 1-step entry in program memory for mux table:
# OK, let's get fancy
# 9d80 allegedly init for mux. 1001 1101 1000 0000 is mux_map_next
# In fact lp5523 driver creates a mux table of one entry length, so
# mux_map_next will spin index in one point and will reload same
# mapping which is pointed to by mux_ld_start and mux_ld_end
# mux_ld_start: 1001 1110 0sss ssss; sssssss = SRAM start addr (0-95)
# mux_ld_end: 1001 1100 1sss ssss; sssssss = SRAM end addr (0-95)
# lp5523 driver executes a short program to load the mapping
# from engineX_leds to the location of mux_ld_start
# Later we might want to use mux_sel to associate _ONE_ LED directly:
# mux_sel: 1001 1101 0bbb bbbb; bbbbbbb = int (0-16), 0=nothing,
# (1-9)=LED1-9; 16=GPO
Attached Files
File Type: txt new-mce.ini.txt (3.8 KB, 82 views)
__________________
Maemo Community Council member [2012-10, 2013-05, 2013-11, 2014-06 terms]
Hildon Foundation Council inaugural member.
MCe.V. foundation member

EX Hildon Foundation approved
Maemo Administration Coordinator (stepped down due to bullying 2014-04-05)
aka "techstaff" - the guys who keep your infra running - Devotion to Duty http://xkcd.com/705/

IRC(freenode): DocScrutinizer*
First USB hostmode fanatic, father of H-E-N

Last edited by joerg_rw; 2014-01-30 at 10:23.
 

The Following 4 Users Say Thank You to joerg_rw For This Useful Post:
Posts: 254 | Thanked: 509 times | Joined on Nov 2011 @ Canada
#45
I now have an MCE compiled that adds the ability to have three engine patterns. I used the ideas discussed here with Joerg. At this point here's what it does:

- Simply turns off the keypad instead of fading it out.

- Looks for a section in the MCE file called [LEDPatternLystiRX51-3Engine] and will use the patterns there if found. If not, it will use the old 2-engine patterns from [LEDPatternLystiRX51] instead.

- If using the 3 engine patterns, maps the LEDs to engines based on three numbers corresponding to RGB (keyboard LEDs not yet implemented.) An extra field is added at the end for the pattern to load to engine 3.

These are the default patterns to work with the 3engine MCE:

Code:
[LEDPatternLystiRX51-3Engine]
PatternError=0;5;0;100;9d8040007f007f0040ff7f007f000000;9d800000;9d800000
PatternDeviceOn=254;0;0;111;9d804000422043207f100000;9d800000;9d800000
PatternDeviceSoftOff=253;0;0;110;9d804000423f433f7f100000;9d800000;9d800000
PatternPowerOn=9;3;0;111;9d80400042ff02ffc000;9d800000;9d800000
PatternPowerOff=10;3;0;111;9d80400001ff43ff7f007f00c000;9d800000;9d800000
PatternCommunicationCall=30;1;0;001;9d80400002ff03ff02ff03ff71080000;9d800000;9d
800000
PatternCommunicationIM=30;1;0;001;9d80400002ff03ff02ff03ff71080000;9d800000;9d800000
PatternCommunicationSMS=30;1;0;001;9d80400002ff03ff02ff03ff71080000;9d800000;9d800000
PatternCommunicationEmail=30;1;0;001;9d80400002ff03ff02ff03ff71080000;9d800000;9d800000
PatternCommonNotification=30;1;0;001;9d80400002ff03ff02ff03ff71080000;9d800000;9d800000
PatternWebcamActive=20;1;0;100;9d80400004ffc0000000;9d800000;9d800000
PatternBatteryCharging=50;4;0;110;9d804000427f0d7f7f007f0042000000;9d800000;9d800000
PatternBatteryFull=40;4;0;010;9d80407f0000;9d800000;9d800000
Things I still would like to do:
- add the ability to control keyboard LEDs to the patterns (by simply extending the LEDsToMap field by 6 digits). I'm not sure whether this will be used or not, but might as well add the functionality. I'm concerned that the normal keyboard LED control might interfere with the keyboard LED control by the engines. Need to test this.
- add the fadeout time back into keyboard.c

Last edited by shawnjefferson; 2014-02-01 at 19:44.
 

The Following 6 Users Say Thank You to shawnjefferson For This Useful Post:
Posts: 804 | Thanked: 1,598 times | Joined on Feb 2010 @ Gdynia, Poland
#46
Originally Posted by shawnjefferson View Post
I now have an MCE compiled that adds the ability to have three engine patterns.

[...]
Would you mind uploading sources somewhere so curious ones could also try playing with it?
 

The Following User Says Thank You to misiak For This Useful Post:
pichlo's Avatar
Posts: 6,445 | Thanked: 20,981 times | Joined on Sep 2012 @ UK
#47
Originally Posted by shawnjefferson View Post
Things I still would like to do:
<snip>
- add the fadeout time back into keyboard.c
If it's not too much to ask, I'd rather have the keyboard backlight on all the time while the keyboard is open. That means no dependency on environment background and similar nonsense. Can that be achieved? That would also make the fade out irrelevant

(Sorry if I've missed something and what I want can be done already.)
__________________
Русский военный корабль, иди нахуй!
 
Posts: 3,074 | Thanked: 12,960 times | Joined on Mar 2010 @ Sofia,Bulgaria
#48
Originally Posted by pichlo View Post
If it's not too much to ask, I'd rather have the keyboard backlight on all the time while the keyboard is open. That means no dependency on environment background and similar nonsense. Can that be achieved? That would also make the fade out irrelevant

(Sorry if I've missed something and what I want can be done already.)
I'd rather not have it on all the time, esp when I am on a beach (for example), or at least that one should be configurable. Don't forget we have only one 1320 mAh battery in the device

@shawnjefferson: while you're at it, could you please look at that bug report, please http://talk.maemo.org/showpost.php?p...0&postcount=34

Also, I think it is a good idea to clone the source code at gitorious and do merge requests for whatever you think might be an improvement/bug fix
__________________
Never fear. I is here.

720p video support on N900,SmartReflex on N900,Keyboard and mouse support on N900
Nothing is impossible - Stable thumb2 on n900

Community SSU developer
kernel-power developer and maintainer

 

The Following 4 Users Say Thank You to freemangordon For This Useful Post:
joerg_rw's Avatar
Posts: 2,222 | Thanked: 12,651 times | Joined on Mar 2010 @ SOL 3
#49
please note that my original mce.ini "specs" of above already have all you asked for. PatternKbdOn/Off would override the internal switch/fade for kbd backlight. Since the ScreenOn parameter would make no sense for kbd-backlight, it could get redefined to specify if kbd bl is sensitive to ALS brightness. Pattern duration of "0" means "stay on always, while open (no timeout)".
Leaving all the engine patterns empty would indicate that mce shall handle the on/off without using LP5523 engines for that (same can get achieved by fadeout-time=0 mce.ini parameter)
__________________
Maemo Community Council member [2012-10, 2013-05, 2013-11, 2014-06 terms]
Hildon Foundation Council inaugural member.
MCe.V. foundation member

EX Hildon Foundation approved
Maemo Administration Coordinator (stepped down due to bullying 2014-04-05)
aka "techstaff" - the guys who keep your infra running - Devotion to Duty http://xkcd.com/705/

IRC(freenode): DocScrutinizer*
First USB hostmode fanatic, father of H-E-N
 

The Following 3 Users Say Thank You to joerg_rw For This Useful Post:
Posts: 254 | Thanked: 509 times | Joined on Nov 2011 @ Canada
#50
If anyone wants to try this out on their own device, here's the recompiled MCE keypad and led modules.

Note: please don't try this if you don't at least know your way around the command-line, and are willing to try experimental code. It's been working fine on my device for over a week, but no guarantee's for your device.

1. Make a backup of /usr/lib/mce/modules/libkeypad.so and /usr/lib/mce/modules/libled.so

2. Copy the two .so files from the zip to /usr/lib/mce/modules on your device

3. Add this section to your mce.ini file (you might want to make a backup of that file first):

Code:
[LEDPatternLystiRX51-3Engine]
PatternError=0;5;0;100;9d8040007f007f0040ff7f007f000000;9d800000;9d800000
PatternDeviceOn=254;0;0;111;9d804000422043207f100000;9d800000;9d800000
PatternDeviceSoftOff=253;0;0;110;9d804000423f433f7f100000;9d800000;9d800000
PatternPowerOn=9;3;0;111;9d80400042ff02ffc000;9d800000;9d800000
PatternPowerOff=10;3;0;111;9d80400001ff43ff7f007f00c000;9d800000;9d800000
PatternCommunicationCall=30;1;0;001;9d80400002ff03ff02ff03ff71080000;9d800000;9d
800000
PatternCommunicationIM=30;1;0;001;9d80400002ff03ff02ff03ff71080000;9d800000;9d800000
PatternCommunicationSMS=30;1;0;001;9d80400002ff03ff02ff03ff71080000;9d800000;9d800000
PatternCommunicationEmail=30;1;0;001;9d80400002ff03ff02ff03ff71080000;9d800000;9d800000
PatternCommonNotification=30;1;0;001;9d80400002ff03ff02ff03ff71080000;9d800000;9d800000
PatternWebcamActive=20;1;0;100;9d80400004ffc0000000;9d800000;9d800000
PatternBatteryCharging=50;4;0;110;9d804000427f0d7f7f007f0042000000;9d800000;9d800000
PatternBatteryFull=40;4;0;010;9d80407f0000;9d800000;9d800000
4. type "stop mce" and then "start mce" to restart mce on your device.

You should now have access to all three engines with your LED patterns and the keypad will not fade out, but simply turn off after the idle timeout.

Note: this is still in development. Attached in the zip file are also the two source files from MCE where I've made changes so you can compile it yourself if you want.

PS. LED Pattern Editor appears to still work fine, but it's using the old patterns... you'll need to edit the mce.ini itself to play with new patterns.
Attached Files
File Type: zip modules.zip (53.1 KB, 68 views)

Last edited by shawnjefferson; 2014-02-02 at 19:58.
 

The Following 9 Users Say Thank You to shawnjefferson For This Useful Post:
Reply

Tags
cssu-mce, fremantle, hdtd thread, htdt detected


 
Forum Jump


All times are GMT. The time now is 12:50.