IRC log for #maemo-ssu on 20131123

00:44.48*** join/#maemo-ssu freemangordon_ (~freemango@46.249.74.23)
01:30.11*** join/#maemo-ssu aap (~drew@cpe-174-101-232-161.cinci.res.rr.com)
02:28.17*** join/#maemo-ssu aap (~drew@cpe-174-101-232-161.cinci.res.rr.com)
03:31.37*** join/#maemo-ssu amiconn_ (amiconn@rockbox/developer/amiconn)
04:20.47DocScrutinizer05in filter-brightness-als.h there's this structure:
04:20.53DocScrutinizer05{
04:20.54DocScrutinizer05{
04:20.56DocScrutinizer05{ 32, 64 },
04:20.57DocScrutinizer05{ 100, 1000 },
04:20.59DocScrutinizer05{ -1, -1 },
04:21.03DocScrutinizer05}, { 5, 5, 0, 0, 0, 0 }
04:21.05DocScrutinizer05}
04:22.04DocScrutinizer05it means indicator LED will work on 5(% brightness?) up til 64LUX, and on 5 up till 1000LUX, above 1000 it switches to 0.
04:22.42DocScrutinizer05could somebody please patch { 5, 5, 0, 0, 0, 0 }  to  { 5, 5, 5, 5, 5, 0 } ?
04:23.34DocScrutinizer05or just { 5, 5, 5, 0, 0, 0 }
04:25.49DocScrutinizer05one char patch ;-)
04:26.00DocScrutinizer05my favourite typ eof patches
04:26.29DocScrutinizer05it's definitely a typo
04:29.41DocScrutinizer05btw we also see that this annoying blanking of indicator LED in bright daylight only happens when brightness profile is set to MAX (aka "5")
04:31.07DocScrutinizer05when you reduce "screen" brightness to anything <MAX/5, some of the former unflawed LED brightness profiles from als_profile_struct led_als_profiles_rx51[] gets used
04:32.29DocScrutinizer05each of the other 4 profiles has N+1 values for N LUX-limit tuples
04:33.58DocScrutinizer05ooops actually not
04:34.36DocScrutinizer05it's totally confusing, it seems like only profile#3 is defined at all
04:34.58DocScrutinizer051,2,4,5 are all all zeroes
04:36.01DocScrutinizer05I skipped a whole page in that struct desert, sorry
04:36.51DocScrutinizer05here you are: http://privatepaste.com/33cb0318d8
04:37.54DocScrutinizer05while a proer definition like something like http://privatepaste.com/aada1e8273
04:38.02DocScrutinizer05proper*
04:38.15DocScrutinizer05looks* dang
04:56.23DocScrutinizer05honestly WTF?! http://privatepaste.com/048a9fe57d
05:53.16*** join/#maemo-ssu LaoLang_cool (~LaoLang_c@183.32.203.89)
06:12.57DocScrutinizer05the structure starts in libfilter-brightness-als.so at 0x85f8
06:15.02DocScrutinizer05thr byte to patch from 0x00 to 0x05 is at 0x86a8
07:18.15*** join/#maemo-ssu unclouded (~neil@2001:4428:200:80fc:7e05:7ff:fe0d:d421)
07:22.24*** join/#maemo-ssu sixwheeledbeast (~paul@cl-1547.lon-02.gb.sixxs.net)
07:54.32*** join/#maemo-ssu LauRoman (~LauRoman@5-14-80-71.residential.rdsnet.ro)
08:00.07*** join/#maemo-ssu LauRoman|Alt (~LauRoman@5-14-80-71.residential.rdsnet.ro)
08:15.46*** join/#maemo-ssu freemangordon (~freemango@46.249.74.23)
08:49.12*** join/#maemo-ssu Pali (~pali@Maemo/community/contributor/Pali)
08:59.50*** join/#maemo-ssu NIN101 (~NIN@p5DD2BE2F.dip0.t-ipconnect.de)
09:01.02*** join/#maemo-ssu _rd (~rd@p5088FDAB.dip0.t-ipconnect.de)
09:08.53*** join/#maemo-ssu BCMM (~BCMM@unaffiliated/bcmm)
09:59.25*** join/#maemo-ssu NIN101 (~NIN@p5DD2BE2F.dip0.t-ipconnect.de)
10:14.40*** join/#maemo-ssu Woody14619 (~Woody1461@Maemo/community/contributor/Woody14619)
10:38.42*** join/#maemo-ssu _rd (~rd@p5088FDAB.dip0.t-ipconnect.de)
10:47.33*** join/#maemo-ssu M4rtinK (~M4rtinK@mail.melf.eu)
11:06.52*** join/#maemo-ssu dafox (~dafox@ip51cc571d.speed.planet.nl)
11:21.33*** join/#maemo-ssu _rd (~rd@p5088FDAB.dip0.t-ipconnect.de)
12:39.47*** join/#maemo-ssu _rd (~rd@p5088FDAB.dip0.t-ipconnect.de)
12:53.55*** join/#maemo-ssu dos1 (~dos@unaffiliated/dos1)
13:02.39*** join/#maemo-ssu okias (~okias@berger.cust.centro-net.cz)
13:15.09*** join/#maemo-ssu BCMM (~BCMM@unaffiliated/bcmm)
15:00.25*** join/#maemo-ssu dos1 (~dos@unaffiliated/dos1)
15:00.27*** join/#maemo-ssu M13 (~MirandaLS@170.133-224-87.telenet.ru)
15:17.35*** join/#maemo-ssu mkaindl (~mkaindl@ama-dablam.markus-kaindl.de)
15:35.05DocScrutinizer05freemangordon: seen the above?
15:35.31freemangordonDocScrutinizer05: hmm? which one?
15:35.47DocScrutinizer05the previous ~40 lines
15:36.02freemangordonjust saw them
15:36.10freemangordonI read on TMO
15:36.17DocScrutinizer05ooh, thanks
15:36.37freemangordonDocScrutinizer05: I'll patch mce in cssu, this patch is a nobrainer
15:36.46DocScrutinizer05yes
15:37.05freemangordonbut I'll need jonwil, there is a report of some problem with mce
15:37.13DocScrutinizer05o.O
15:37.28freemangordonhttp://talk.maemo.org/showpost.php?p=1387420&postcount=34
15:38.01freemangordonsounds weird, but still
15:39.00DocScrutinizer05:-/
15:39.08DocScrutinizer05confirm it?
15:39.44DocScrutinizer05I mean, the description is clear enough to either reproduce or reject as invalid?
15:40.16freemangordonsure, that is why I wait for jonwil to appear, my confirmation without a fix is useless
15:40.24freemangordonI guess it is not invalid
15:40.31freemangordon(the report)
15:41.05freemangordonis going to check the stck behaviour
15:41.09freemangordon*stock
15:44.53freemangordonyep, with stock mce pushing a button after the display was dimmed on timeout, unlocks it
15:48.05DocScrutinizer05please elaborate
15:48.41freemangordonopen the keyboard, let the screen to dim and press a button on the keyboard
15:48.52DocScrutinizer05yes, unlocks screen
15:49.20DocScrutinizer05even qualifier keys like shift do
15:49.25freemangordonnot on mce replacement it seems:
15:49.28DocScrutinizer05and the keypress gets eaten
15:49.35freemangordon"... the keyboard gets locked and can only be unlocked when touching the display"
15:50.30DocScrutinizer05this btw works in both states: dim and blank display
15:50.45freemangordon:nod:
15:51.03DocScrutinizer05in dim it has a setting "lock on dim" or sth like that, in mce.ini, IIRC
15:51.27DocScrutinizer05I may be mistaken on that though
15:51.36DocScrutinizer05it doesn't make sense
15:51.52DocScrutinizer05checks mce.ini
15:55.17DocScrutinizer05# Policy for keypad interrupts
15:55.19DocScrutinizer05#
15:55.20DocScrutinizer05# 2 - leave keypad interrupts on even after blanking
15:55.22DocScrutinizer05#     (used to support pass-through of +/-)
15:55.23DocScrutinizer05# 1 - disable interrupts immediately
15:55.25DocScrutinizer05# 0 to wait until display is blanked
15:55.26DocScrutinizer05DisableKPImmediately=1
16:02.06DocScrutinizer05freemangordon: I have quite a number of patches for mce, for sanitizing the ill-conceived LP5523 handling. Starting with freeing up engine 3 from that idiotic exclusive task of 100ms kbd backlight ramping, and continuing with an augmented syntax for pattern definitions, and of course also allowing to exploit full program memory available in LP5523 which is twice the size of what mce (and the kernel driver) supports
16:03.14freemangordonDocScrutinizer05: sorry, preparing new -thumb update right now, cannot share time for mce :)
16:03.29DocScrutinizer05no problem, I'll provide patches
16:04.10DocScrutinizer05also for lp5523.ko
16:04.52DocScrutinizer05rGB *pfff*
16:05.15DocScrutinizer05122 maybe
16:05.46DocScrutinizer05#         "r", "g", "b" maps the LED to engine 1
16:05.47DocScrutinizer05#         "R", "G", "B" maps the LED to engine 2
16:05.49DocScrutinizer05#         Example:
16:05.50DocScrutinizer05#            "rG" maps the red LED to engine 1,
16:05.52DocScrutinizer05#                      the green LED to engine 2,
16:07.29DocScrutinizer05the nice part is a "312" (for R=engine3, G=engine1, B=2) is compatible with that "rGb" scheme
16:10.11DocScrutinizer05and of course extending pattern length is a nobrainer, as is appending pattern for engine3
17:15.05*** join/#maemo-ssu thedead1440_ (~thedead14@unaffiliated/thedead1440)
17:15.44*** join/#maemo-ssu xes (~xes@unaffiliated/xes)
17:18.36*** join/#maemo-ssu thedead1440_ (~thedead14@unaffiliated/thedead1440)
17:37.32*** join/#maemo-ssu _rd (~rd@p5088FDAB.dip0.t-ipconnect.de)
18:01.09DocScrutinizer05freemangordon: hey guy, you're still alive?
18:01.57DocScrutinizer05not that we were in a particular hurry to fix a autobuilder lockup that's already lingering since 4 days
18:02.06DocScrutinizer05;-)
18:03.38DocScrutinizer05also would be highly appreciated when you /join the admin channel
18:19.00kerioDocScrutinizer05: aww, that patch will make the modified filter-brightness-als obsolete
18:19.07kerioand i don't know if the dude who made it is still around
18:20.38DocScrutinizer05kerio: hmm?
18:21.50DocScrutinizer05kerio: which patch? why does it make anything obsolete?
18:22.31DocScrutinizer05and what?
18:22.48keriofilter-brightness-als.so
18:22.54kerioone of the mce thingies
18:23.20DocScrutinizer05yes, that's the one where you need to patch one byte to fix the indicatior LED
18:23.44kerioit's one byte in C
18:23.51keriowho knows how many bytes it will be when compiled
18:23.57keriomaybe everything changes
18:24.05DocScrutinizer05http://talk.maemo.org/showthread.php?t=91849
18:24.16kerioyay
18:25.06DocScrutinizer05and yes, I should clearly state which binary this instructions apply to
19:00.21PaliDocScrutinizer05: you have patches for kernel driver lp5523.ko?
19:05.31*** join/#maemo-ssu Pali (~pali@Maemo/community/contributor/Pali)
19:24.05DocScrutinizer05Pali: yep, though nothing tested for even compiling without flaws
19:24.35DocScrutinizer05Pali: didn't come around to setting up a buld environment
19:24.39PaliDocScrutinizer05: if you want patch to be included in kp53, post it to kp TMO thread
19:25.09Palior send me it or upload it
19:25.24DocScrutinizer05sure, will do as soon as I can check anything for at least syntactical correctness
19:25.30Palijust I need to know if to wait for patch or relese version without it
19:25.33Paliok
19:27.34*** join/#maemo-ssu nox- (noident@freebsd/developer/nox)
19:30.45*** join/#maemo-ssu arcean (~arcean@aaeq229.neoplus.adsl.tpnet.pl)
19:39.17*** part/#maemo-ssu mkaindl (~mkaindl@ama-dablam.markus-kaindl.de)
19:42.04DocScrutinizer05don't wait
19:42.47DocScrutinizer05it's not even in any state to consider publishing anything yet - maybe except for the API extension specs
19:56.26DocScrutinizer05kerio: I still fail to see why my "patch" obsoletes anything
19:56.45keriowell apparently your patch is a hex edit too
19:57.12DocScrutinizer05so?
19:57.17kerioso it's false
19:57.29DocScrutinizer05*shrug*
19:57.44DocScrutinizer05CBA to argue about that
19:58.05keriomy fear was that if it was a patch that needed a recompile
19:58.15keriothen the previous hex editing would require more finesse to be applied again
19:58.46DocScrutinizer05so?
19:59.03DocScrutinizer05I still don't see what's wrong with my patch
19:59.11keriothere's nothing wrong
19:59.15kerioit's actually much better
20:48.39Palifreemangordon: ping
20:50.27Palifreemangordon: new version of qt4-x11 and hildon-desktop is in git, but not in cssu-devel
20:50.59Palisame for status-area-orientationlock-applet
20:51.01*** join/#maemo-ssu _rd (~rd@p5088FDAB.dip0.t-ipconnect.de)
20:52.37Paligoing to build status-area-orientationlock-applet and push it to cssu-devel
20:53.27Palidone
21:40.14*** join/#maemo-ssu LauRoman (~LauRoman@5-14-80-71.residential.rdsnet.ro)
22:02.42freemangordonPali: I've fixed h-d today, will push it in -devel tomorrow
22:02.51Paliok
22:03.14freemangordonPali: is there something fixed in qt?
22:03.36Paliyes, because in git is newer version as in cssu-devel
22:04.14freemangordonPali: any clue what is fized?
22:04.17freemangordon*fized
22:04.20freemangordonshit
22:04.22freemangordonFIXED
22:04.26Palido not know
22:04.38freemangordonhmm, ok, will check
23:02.03*** join/#maemo-ssu LauRoman|Alt (~LauRoman@5-14-86-200.residential.rdsnet.ro)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.