IRC log of #maemo for Saturday, 2016-01-02

*** justingo has joined #maemo00:02
*** justingo has quit IRC00:03
*** justingo has joined #maemo00:04
*** justingo has quit IRC00:05
*** justingo has joined #maemo00:05
Palifreemangordon: you need to compile gpio-keys.ko00:07
Paliand then via /dev/input/event<num> ask for switch status00:07
Palicurrently gpio-keys.ko is disabled in linux-n900 tree CONFIG_KEYBOARD_GPIO=m is needed for it00:08
*** justingo has quit IRC00:09
freemangordonPali: and how do you distinguish between various switch types? is there interface for it?00:11
freemangordonPali: and what "ask" means? poll()?00:11
Palifreemangordon: yes, each switch has its own "code"00:11
Palilike key press00:11
Palievery key has its own code00:12
Palikeypad_slide --> gpios = <&gpio3 7 GPIO_ACTIVE_LOW>; /* 71 */ --> linux,code = <0x0a>; /* SW_KEYPAD_SLIDE */00:12
Paliall is defined in DTS00:13
freemangordonoh, so we open all the stuff in /dev/input and wait for KEY_SLIDE on all of the descriptors?00:13
Palinot all stuff in /dev/input00:13
Palijust one device which has that name gpio-keys00:13
freemangordonwhere is that "name" defined? in /sys/input/devices?00:14
*** justingo has joined #maemo00:15
jonwilPali: Is the intent that upstream kernel works with stock bme or will upstream kernel need your bme replacement?00:21
jonwilactually, it doesn't matter :)00:23
freemangordonjonwil: it needs bme-replacement00:23
jon_yare we getting kernel 4.x yet? :)00:26
Palifreemangordon: name is defined in DTS too00:27
Palijonwil: upstream kernel works with bme replacment00:28
*** robink has quit IRC00:39
*** robink_ has joined #maemo00:42
*** futpib_ has quit IRC00:45
*** realitygaps has quit IRC00:47
*** realitygaps has joined #maemo00:50
*** realitygaps has joined #maemo00:50
*** justingo has quit IRC00:54
DocScrutinizer05freemangordon: ((point is that we *must not* hardcode paths)) must not as in "upstream will kill us" or any technical reasons? My take on this is a tad "anachronistic" since I think an embedded device doesn't need a general purpose kernel but should use its own tailored-to-fit lean kernel derived from upstream by pruning01:03
Wizzuphaving an upstream kernel is great for many reasons01:04
Wizzupfor one - grsecurity :)01:04
DocScrutinizer05well, having an upstream jkernel doesn't mean you need *all* of that stuff, most is cruft for your particular device01:05
WizzupI don't see why you would hardcode paths if there are more sensible ways to do it that will save time/problems in the future :)01:05
WizzupEither way, I'm happy with the work that seems to be done!01:05
*** erlehmann has joined #maemo01:06
DocScrutinizer05because such generic stuff costs storage and memory and runtime01:06
*** Pali has quit IRC01:07
DocScrutinizer05e.g. for hostmode we had to kick out a shitload of cruft that got in the way with USB enum and hubs and whatnot01:07
*** erlehmann has quit IRC01:08
DocScrutinizer05but I don't want to argue, I know I won't make a point against 99% of devels01:08
DocScrutinizer05I just see that basically every commercial embedded device I've ever seen has his own private branch of kernel, with patches sometimes eventually getting upstreamed, sometimes never01:09
Wizzupwhich is dreadful for security and interoperability01:10
WizzupI don't think some generic path resolve will use that much mem/storage/runtimecpu01:10
DocScrutinizer05err why? as long as upstream patches apply to your local branch?01:10
Wizzupbecause it is a PITA to maintain01:10
jonwilPali: Do we have a list somewhere of all interfaces under /sys and /proc that have changed between N900 stock kernel and upstream kernel?01:11
Wizzupkeeping track of all the security patches, let alone bug fixes01:11
Wizzupjonwil: he left01:11
jonwiloh ok01:11
DocScrutinizer05tzz, that's the "I'm too lazy" argument that naver resulted in technically optimized solutions01:11
Wizzupjonwil: maybe the wiki article he mentioned helps (I guess you saw it already)01:11
jonwilnope, that doesn't help so much01:11
DocScrutinizer05as long as you do smart 'proprietary' patches to your branch, upstream security and maintenance patches should apply without any conflict01:13
Wizzupbut why bother if you can just use the latest version? why spend many hours on something that is already taken care of01:13
Wizzupanyway, I also don't want to argue :)01:13
DocScrutinizer05because of the headache freemangordon has with "what do we do with changing/differing GPIO numbers on same platform"01:16
DocScrutinizer05for example01:16
DocScrutinizer05embedded is *way* more different from platform to platform than your average PC differs between Dell and younameit01:17
DocScrutinizer05and the complexity of those differences typically is of the class that has no proper means to deal with it at all in a generic kernel01:18
keriomy embedded ARM home server runs mainline linux01:18
Wizzupkerio: mine too :)01:18
Wizzupmy arm laptop too01:18
kerioand it's awful01:19
keriobecause it's not bsd01:19
DocScrutinizer05kerio: then prolly because some poor sods upstreamed the patches needed to make the linux run on that platform01:19
keriomaemo has *two* poor sods01:19
WizzupDocScrutinizer05: what's with the hate? Why isn't it awesome that we can use stuff like btrfs on ARM home servers?01:19
WizzupSome things takes so much work to backport to older versions, when you can simple use the latest LTS / mainline version01:19
DocScrutinizer05you totally lost me01:20
Wizzuppoor sods -> great people01:20
Wizzupis my point mostly01:20
Wizzupguess I misunderstood01:20
kerioDocScrutinizer05: being able to run mainline means that you get access to new features01:20
kerioand they can be good01:20
DocScrutinizer05so what?01:20
WizzupThat can often means better performance, lower memory usage, more bug fixes, etc, etc.01:21
WizzupBetter crypto, other things relevant to embedded01:21
DocScrutinizer05in the old day every PC had to compile its own kernel. And that had its advantages since the kernel was small and fast and tailored to fit. And there was zilch problem to run the "make kernel" on your installation interim system. You did that one and voila01:22
WizzupI still do that for all my machines01:22
WizzupAnd you can also do that for the N900 with mainline/upstream01:22
kerioDocScrutinizer05: that's not at all what "mainline kernel" means01:22
kerioor, rather01:23
keriothat's not in contradiction with01:23
DocScrutinizer05it's your arguing about mainline. I never had objections against mainline, I only said each embedded has its own branch where you keep the stuff that hasn't yet, or can't at all get upstreamed01:24
Wizzupthere are quite some arm devices where everything is upstreamed :)01:24
DocScrutinizer05and you might want to prune that branch to kick out obviously cruft items01:24
WizzupI think for the n900, where the bits are not upstreamed, they are in some branch. Like with amd64 platform drivers01:25
DocScrutinizer05ARM doesn't need PCI-support01:25
DocScrutinizer05nor fan sensor support01:25
DocScrutinizer05nor weird AMD graka drivers01:25
WizzupJetson TK1 has PCI slots01:26
WizzupTX1 has them too01:26
Wizzupand the ARM servers have them too01:26
DocScrutinizer05N900 has _not_ exactly my point01:26
WizzupYou said "ARM" :)01:26
kerioneo900 feature request: pci express01:26
*** lobito1 has quit IRC01:26
Wizzupmerlijn@deepwater ~ $ sudo zgrep CONFIG_PCI /proc/config.gz01:26
Wizzup# CONFIG_PCI is not set01:26
Wizzup^arm machine01:27
Wizzupnot hard to disable :)01:27
DocScrutinizer05ok, and what do you do when it starts to be hard or impossible?01:27
kerioyou file a bug01:28
kerioit's linux, not systemd01:28
Wizzupgnu/linux in the case of the n90001:28
* Wizzup hides01:28
DocScrutinizer05like with lis302 driver which is completely brainfucked in upstream, and will cut through your battery in no time01:28
keriothe maintainer yells at the other devs, not at the users01:28
kerioWizzup: no, "linux" is quite specifically correct here01:28
Wizzupkerio: I realised ;-)01:29
WizzupI just felt trolly01:29
WizzupI'll go and hit the sack :)01:29
*** lobito has joined #maemo01:31
freemangordonDocScrutinizer05: reasons are technical, I give a shit about politics and you know it :)01:44
freemangordonvery similar to what Wizzup said - the cost of maintenance and platform independence01:45
freemangordonwhy we should have HW specific stuff if we can skip it01:47
freemangordonfor example - if we use generic interface, the board package could simply contain a script creating HW specific symlinks for various devices existing in the platform implementing predefined API01:48
freemangordonor what Pali said ^^^ - using generic /dev/input interface with board file providing the HW specific settings01:49
freemangordonDocScrutinizer05: also, believe it or not, but upstream kernel runs waaay faster that stock, when it works ofc01:50
freemangordonwe have things like neon-optimized functions, RCU, lots of optimizations, etc, etc01:51
freemangordonI am not thinking N900 or Neo900 here, but Maemo01:52
freemangordonfrom the POV of the userspace it should not matter what platform it is and whether it is embedded or server01:52
freemangordonalso, having HW support upstreamed doesn't mean you cannot use device specific kernel - and that is what we use to boot upstream on N900, there is rx51_defconfig in arch/arm/configs, which enables only what is needed on N90001:54
DocScrutinizer05then you run into sever trouble, since userland will need to behave differently for different platforms. This starts with N800 vs N900, where we either have pop-out camera or two camreas and a camdoor for one of both01:54
freemangordonbut we should not run in troubles for simple stuff like gpio swithes and sensors, yet we do as all the userspace is tailored for a specific HW01:55
DocScrutinizer05you can't expect same kernel API on different platforms01:55
*** esaym has joined #maemo01:55
freemangordona switch is a switch, dammit01:56
DocScrutinizer05because one has a LCD and the other OLED, one a c-ts and the other a r-ts, and so on01:56
*** heroux_ has joined #maemo01:56
*** keithzg_ has joined #maemo01:56
freemangordonok, lets assume it is harder to do it for complicated HW like TS and camera, but again - a SWITCH?01:57
*** stryngs has quit IRC01:57
*** luke-jr_ has joined #maemo01:57
DocScrutinizer05and even a switch is not like any other. Think of one device having a pushbutton to enable and disable screenlock, while the other device has a slide throwswitch that has a locked and a unlocked position01:58
freemangordonDocScrutinizer05: ever heard of WOSA/XFS?01:58
DocScrutinizer05should I?01:59
*** clopez has quit IRC02:00
*** esaym153 has quit IRC02:00
*** heroux has quit IRC02:00
*** auenfx4 has quit IRC02:00
*** keithzg has quit IRC02:00
*** chainsawbike has quit IRC02:00
*** discopig has quit IRC02:00
*** ceene has quit IRC02:00
*** Luke-Jr has quit IRC02:00
*** ceene has joined #maemo02:00
*** smhar has quit IRC02:00
*** mickname has quit IRC02:00
*** inz has quit IRC02:00
*** jrayhawk_ has quit IRC02:00
*** chfoo- has quit IRC02:00
*** juiceme has quit IRC02:00
*** heroux_ is now known as heroux02:00
keriofreemangordon: now look at what you've done02:00
freemangordonif it is possible to make an unified API to control complicated devices like card readers, cash dispensers and acceptors, etc, I don;t see why the fucjk we cannot have such an api for a swicth (or push button) or whatever you like to call it02:00
*** auenfx4 has joined #maemo02:00
freemangordonyeah :)02:00
*** juiceme has joined #maemo02:00
*** LjL has quit IRC02:00
*** Milhouse has quit IRC02:00
*** inz has joined #maemo02:00
*** chfoo- has joined #maemo02:01
*** chainsawbike has joined #maemo02:01
*** jrayhawk has joined #maemo02:01
*** pozitrono has joined #maemo02:01
*** juiceme is now known as Guest7802402:01
*** pozitrono has quit IRC02:01
*** LjL has joined #maemo02:02
*** smhar has joined #maemo02:02
*** clopez_ has joined #maemo02:02
DocScrutinizer05well, as long as you don't upstream your brilliant unified switch API, it is again a proprietary stuff for your very own hw platform only02:02
freemangordonbut, it seems it is already upstreamed, according to Pali and is called gpio-key :)02:03
keriohardware people talking about software is almost as bad as software people talking about hardware :<02:03
DocScrutinizer05and don't get me wrong, I *cursed* dbus and HAL and friends to hell for their crappy handling of button/switch events02:03
freemangordonbut yeah, as SW switch does not fit into that gpio-switch02:04
*** stryngs has joined #maemo02:04
*** stryngs is now known as Guest5455402:04
freemangordonbut then you have a way to create stuff in /dev/input02:04
freemangordonkerio: neither me nor DocScrutinizer05 are SW only or HW only guys02:05
*** mickname has joined #maemo02:05
DocScrutinizer05I also think it's insane that mce has to check GPIO57 or whatever to learn if kbd is open or cam trigger pressed02:05
DocScrutinizer05freemangordon: ack :-D02:06
freemangordonexactly. But this is what happens when you make SW with a particular HW platform in mind02:06
freemangordonI really don't get it why power buttons and volume keys produce KBD events, but lock switch and slider do not02:07
freemangordonin stick kernel that is02:08
freemangordonanyway, getting late here , /me going to have some sleep02:08
freemangordonnight guys02:08
DocScrutinizer05I think if you could use DT or boardfile to devine abstract and speaking (file)names for all MMI elements, this would be outright great. Then I just would miss the config dialog in camera-ui where I can browse the according branch of filesystem tree to define if I want button+/- or button-focus/trigger for the camera, or I go fancy and define switch-kbdslide as camera trigger02:09
infobotDocScrutinizer05 meant: I think if you could use DT or boardfile to define abstract and speaking (file)names for all MMI elements, this would be outright great. Then I just would miss the config dialog in camera-ui where I can browse the according branch of filesystem tree to de...02:09
DocScrutinizer05...or holdbutton-headset02:10
DocScrutinizer05in a way quite similar to what you do in decent programs to define your audio device02:11
freemangordonno, you would not miss that dialog, as you will be able to tell it to use whatever you want from the list of the available input switches in the system02:11
freemangordonanyway, night02:12
DocScrutinizer05:-) night!02:13
DocScrutinizer05I always thought that /sys/*/bla/GPIO/* approach was pretty kinky02:13
DocScrutinizer05nice for hackers who know the device by heart. But a nightmare for everybody else, including userland app devels02:14
*** luke-jr_ is now known as Luke-Jr02:14
*** Milhouse has joined #maemo02:14
DocScrutinizer05even /dev/input/* is quite obfuscated and messed up02:16
DocScrutinizer05what you need is an "expert" service where you can search for all sorts of properties of a MMI element, and the service tells you whatever cryptic name in /dev or /sys you should use when you decide you want to use that interesting "mechanic analog input degrees-of-freedom:1 type:slider location:surface-right,position-center,orientation-updown range:0-100"02:20
DocScrutinizer05I don't suggest any busses (dbus) or the like since they introduce too much overhead and jitter and lag02:22
DocScrutinizer05you don't want to play a electric piano keyboard when it gets interfaced via dbus messages02:23
WizzupWhat is obfuscated about /dev/input?02:25
DocScrutinizer05you need pretty straight access to the state of a GPIO or A/D converter, only a few hundred lines of c code at most (in total, in all layered drivers etc) until you get the return value, but you need an expert that tells you where and how to get that info, and what type of MMI element that is you're touching there02:25
Wizzup#include <linux/input.h> and go02:26
WizzupDocScrutinizer05: ls -lsh /dev/input/by-id02:27
Wizzupsame for by-path02:27
Wizzup0 lrwxrwxrwx 1 root root 9 Jan  1 20:53 usb-0d8c_C-Media_USB_Headphone_Set-event-if03 -> ../event402:27
Wizzup0 lrwxrwxrwx 1 root root 9 Jan  1 20:53 usb-Logitech_USB_Optical_Mouse-event-mouse -> ../event102:27
Wizzup0 lrwxrwxrwx 1 root root 9 Jan  1 20:53 usb-Logitech_USB_Optical_Mouse-mouse -> ../mouse002:27
DocScrutinizer05still pretty fuzzy gibberish, but yeah a tad better02:27
WizzupI used it extensively when messing around with virtual input device creation, forwarding it over the network, remapping02:28
Wizzupwas fun02:28
Wizzupthe main thing that troubled me were all the KEY_ constants02:28
DocScrutinizer05it's still almost a miracle (and completely unfeasible) to me to put the 13 buttons of my mouse to any purpose02:30
Wizzupso the -event-kbd/mouse are normal linux/input.h devices, the -mouse (without input) using the older mouse api, and I have no clue why the pc speaker is there02:30
WizzupDocScrutinizer05: you may be interested in
DocScrutinizer05some are mapped to a kbd key event, some are mouse events, I even suspect there's a 3rd and 4th and 5th class which all yet behave different to the former two02:31
WizzupYou can achieve exactly that (remapping buttons to other buttoms)02:31
Wizzupbuttons* even02:31
WizzupThere is an older/outdated version in maemo repos that I need to update02:31
DocScrutinizer05prominent example: search key on mouse02:32
DocScrutinizer05which acts as if it was a kbd key02:32
Wizzupanyway /me wrote the sw, so it's a bit of a plug but also related :)02:33
DocScrutinizer05pc-speaker is prolly a jack-insert event02:33
Wizzupif you ever want to mess around with those extra mouse buttons, let me know when it's not 1:30 am :D02:33
WizzupI thought pc-speaker was almost one of those things that you have to strip from the mobo02:33
infobotWizzup meant: I thought pc-speaker was always one of those things that you have to strip from the mobo02:34
Wizzupthe one that generate the annoying terminal bells, making you want to rmmod pcspeaker02:34
DocScrutinizer05I wish mine did more frequently02:35
DocScrutinizer05I think the only sw that uses pc-speaker anymore is eagle02:35
Wizzupttys do too02:36
Wizzupjust type ^K (iirc terminal bell) in a tty02:36
DocScrutinizer05(mess with mousebutton) there's a forward/back button pair I'd love to assign a new hotkey meaning to in KDE02:37
Wizzupevtest (and my own input-read) can dump all the keys a node in /dev/input/ exports02:38
DocScrutinizer05G wie Glocke02:38
Wizzupyou can assign the mouse buttons to any key in /usr/include/linux/input.h02:38
DocScrutinizer05ok, I want them to get assigned to KEY_BACK and KEY_FORWARD, say02:42
*** Ras_Older has joined #maemo02:44
DocScrutinizer05hmm no evtest02:45
Wizzupso you want to know what keys they are, and map those to a different key in the config. uinput-mapper will then create a new input device based on the mouse and 'grab' it so the real mouse events are no longer send02:45
Wizzupand kde will automatically pick up the new mouse/keyboard02:45
DocScrutinizer05that was an easy one, just installed it02:45
WizzupI need to sleep though - happy to help tomorrow02:46
Wizzupor whenever I wake up02:46
DocScrutinizer05from:   evtest --grab by-id/usb-Logitech_Logitech_BT_Mini-Receiver_001F2051A1CA-event-mouse02:50
DocScrutinizer05Wizzup: you're right, time to chillax (new antileete word)02:52
DocScrutinizer05...and the mx-revolution needs a battery recharge too, or no mouse events whatsoever will be available to redirect ;-)02:53
DocScrutinizer05the damn battery is worn02:53
*** xorly has quit IRC02:57
*** florian has quit IRC03:03
*** sq-one has quit IRC03:15
*** robbiethe1st has joined #maemo03:27
*** LauRoman has quit IRC03:58
*** LauRoman|Phone has joined #maemo03:58
*** eMHa_ has joined #maemo04:17
*** eMHa has quit IRC04:20
*** Defiant has quit IRC04:41
*** Defiant has joined #maemo04:42
*** louisdk has quit IRC05:17
*** louisdk has joined #maemo05:28
*** louisdk has quit IRC05:46
*** lobito has quit IRC05:58
*** lobito has joined #maemo06:00
*** DocScrutinizer05 has quit IRC06:04
*** DocScrutinizer05 has joined #maemo06:05
*** louisdk has joined #maemo06:17
*** louisdk has quit IRC06:24
*** Vajb has joined #maemo07:30
*** protem has quit IRC07:33
*** robbiethe1st has quit IRC07:45
*** jonwil has quit IRC07:59
*** vahe has joined #maemo08:08
*** sparetire_ has quit IRC08:25
*** pozitrono has joined #maemo09:40
*** robink_ has quit IRC09:50
*** robink_ has joined #maemo09:50
*** LauRoman|Phone has quit IRC09:55
*** LauRoman has joined #maemo10:07
*** qwazix has quit IRC10:33
*** jonwil has joined #maemo10:34
brolin_empeyjonwil: ’lo.10:50
*** qwazix has joined #maemo10:51
*** pozitrono has quit IRC11:10
*** Pali has joined #maemo11:14
*** Pali has quit IRC11:23
*** Pali has joined #maemo11:33
*** Bono_NL has joined #maemo11:36
*** florian has joined #maemo11:41
*** Bono_NL has quit IRC12:07
*** Bono_NL has joined #maemo12:08
*** futpib_ has joined #maemo12:19
*** realitygaps has quit IRC12:21
*** Bono_NL has quit IRC12:22
*** LauRoman has quit IRC12:25
*** realitygaps has joined #maemo12:32
*** realitygaps has quit IRC12:32
*** realitygaps has joined #maemo12:32
*** ssvb_ has quit IRC12:36
*** ssvb_ has joined #maemo12:37
*** ssvb_ has quit IRC12:40
*** ssvb_ has joined #maemo12:40
*** jonwil has quit IRC13:02
*** realitygaps has quit IRC13:02
*** abdullah has joined #maemo13:05
*** realitygaps has joined #maemo13:07
*** abdullah has quit IRC13:19
*** Vajb has quit IRC13:19
*** Hurrian has quit IRC13:20
*** Hurrian has joined #maemo13:23
*** Hurrian has quit IRC13:28
*** Hurrian has joined #maemo13:31
*** discopig has joined #maemo13:35
*** florian has quit IRC13:35
*** realitygaps has quit IRC13:38
*** realitygaps has joined #maemo13:39
*** realitygaps has joined #maemo13:39
freemangordonPali: what about something like
freemangordonthe only problem is that events are registered with a delay, but I guess this can be fixed13:53
Palifreemangordon: looks good13:57
Palionly one problem is in ALS_PATH_RX51_3x13:57
Palipath via i2c-adapter is not stable13:58
freemangordonyeah, I forgot I touched that one too. But anyway, ^^^ is just POC13:58
freemangordonI know13:58
Palithere should be more stable symlink in /sys somewhere13:58
freemangordonPali: any clue why events might come delayed? the way mce sets giomonitor?13:58
Palifirst check that kernel does not delay them13:59
Paliuse e.g. program input-events13:59
freemangordonevtest spits them immediately13:59
Palithen it is somewhere in mce..14:00
freemangordonanyway, have to leave now, will look at the issue later14:00
freemangordonyes, something in mce14:00
freemangordonbb for now14:00
WizzupHow much are they delayed?14:00
freemangordonhard to say, but more than a second14:00
freemangordonalso, it is not the same everytime14:00
*** Vajb has joined #maemo14:16
*** pharacker has joined #maemo14:25
*** Oksanaa has joined #maemo14:31
*** pharacker has quit IRC14:32
*** xorly has joined #maemo14:32
OksanaaI think that khweeteur does not bother to rm cache-avatars (up to 20MB) from home/user when being purged-uninstalled. Anybody up to confirming-denying?14:35
*** louisdk has joined #maemo14:49
*** florian has joined #maemo15:03
DocScrutinizer05man apt15:04
*** raandoom has joined #maemo15:08
*** realitygaps has quit IRC15:15
*** realitygaps has joined #maemo15:16
*** realitygaps has quit IRC15:16
*** realitygaps has joined #maemo15:16
*** raandoom has quit IRC15:22
*** raandoom has joined #maemo15:24
*** abdullah has joined #maemo15:29
*** abdullah has quit IRC15:30
DocScrutinizer05it's of course arguable if those avatar files are really 'config data'15:30
keriothey're not15:31
DocScrutinizer05but I think the general take on this is "never delete anything from user's home"15:31
keriothe cache should really not be in /home/user though15:32
kerioi guess that storing it in MyDocs becomes complicated, however15:32
*** SmilyOrg has joined #maemo15:34
DocScrutinizer05how so?15:35
kerioMyDocs gets unmounted at the user's will15:35
keriostupid decisions all around, really15:36
DocScrutinizer05well, that's the sort of compromises you need to do when you got only 240MB of /15:36
*** Djgio07 has joined #maemo15:36
DocScrutinizer05though ~optification is really a headache15:37
*** Smily has quit IRC15:37
*** Djgio07 has left #maemo15:38
DocScrutinizer05when the avatar data is no user's config data then it belongs into /opt15:38
DocScrutinizer05at least on a genuine maemo5 system15:39
*** louisdk has quit IRC15:39
DocScrutinizer05and yes, it should get cleaned out then15:39
DocScrutinizer05"forgot to clear the cache" sounds like a common mistake15:39
DocScrutinizer05or at your discretion s/cache/tmp/15:41
*** SmilybOrg has joined #maemo15:47
*** SmilyOrg has quit IRC15:51
*** FlameReaper-PC has joined #maemo15:51
*** SmilyOrg has joined #maemo15:53
*** realitygaps has quit IRC15:55
*** realitygaps has joined #maemo15:56
*** realitygaps has joined #maemo15:56
*** SmilybOrg has quit IRC15:56
KotCzarnyone another thing to consider, with generic inputs/gpio, one could try redefining other button/event source (to unlock the screen for example)15:56
KotCzarnyor to redefine depending what is running etc15:57
KotCzarnywith hardcoded settings there is no such flexibility15:57
*** raandoom has quit IRC16:05
*** raandoom has joined #maemo16:06
*** louisdk has joined #maemo16:08
*** krnlyng has quit IRC16:13
*** totalizator has quit IRC16:13
*** totalizator has joined #maemo16:14
*** krnlyng has joined #maemo16:14
*** raandoom has quit IRC16:15
*** raandoom has joined #maemo16:15
*** Ongkut has joined #maemo16:21
*** Ongkut has quit IRC16:22
*** Ongkut has joined #maemo16:24
*** Ongkut has quit IRC16:24
*** Oksanaa has quit IRC16:37
freemangordonKotCzarny: why is that? We can always introduce switch<->functionality mapping file16:40
freemangordonor gconf or whatever16:40
Palifreemangordon: how hard would be to fix dsp driver and include it again into upstream kernel?16:47
Paliyou already played with that code, so maybe you could know...16:47
*** trumee has quit IRC16:52
*** trumee has joined #maemo16:53
freemangordonPali: they want remoteproc driver. and that wouldn;t be easy16:54
freemangordoni'll need remoteproc coff fw loader and who knows what else16:54
*** Vajb has quit IRC16:58
*** trumee has quit IRC17:03
*** trumee has joined #maemo17:04
*** Vajb has joined #maemo17:09
*** trumee has quit IRC17:13
*** trumee has joined #maemo17:20
Palifreemangordon: what is remoteproc?17:28
*** realitygaps has quit IRC17:32
Palinow last version of tidspbridge cannot be compiled anymore (on uptream kernel)...17:32
*** realitygaps has joined #maemo17:36
*** realitygaps has quit IRC17:36
*** realitygaps has joined #maemo17:36
Paliin old TODO for tidspbridge is nothing about remoteproc17:36
Palithere is just: DOFF binary loader: consider pushing to user space17:37
Palionly *consider*17:37
*** ced117 has quit IRC17:49
freemangordonPali: ok, it turned out some timeout exists in mce re misc input devices, I added a new "class" switch devices with all callbacks etc and now unlocking, slide etc is instant18:01
Palifreemangordon: ok18:02
*** raandoom has quit IRC18:03
*** ced117 has joined #maemo18:05
Palinow I'm looking at mce/modules/vibrator.c and this code is not compatible with upstrem kernel too...18:10
Palipath /sys/class/i2c-adapter/i2c-1/1-0048/twl4030_vibra/pulse does not exist18:10
freemangordonvibrator is exported via evdev as well18:10
Palilooks like that upstream kernel export twl4030 via input layer too!18:10
Paliand twl4030-vibra is registered under audio device18:11
freemangordonjust a second do boot18:12
Palibut problem is that event5 name is not stable18:16
freemangordonso what?18:16
Wizzupuse by-id or by-path18:16
freemangordonno by-id18:16
WizzupOr is that not available?18:16
WizzupYeah, that18:16
Palineed to match against "Input device name" (which is "twl4030:vibrator")18:16
WizzupPali: ls /dev/input/by-id :)18:16
freemangordonPali: we can add another class18:17
Palior maybe just "*:vibrator"18:17
freemangordonthe same way I did for switches18:17
freemangordonPali: no, we'd rather mach on EV_FF18:17
freemangordoninstead of a name18:17
freemangordonI was thinking the same for gpio-keys18:17
PaliWizzup: no by-id in Maemo :-(18:17
Palifreemangordon: yes, match against EV_FF could work too18:18
freemangordonto parse supported keys/switches and to choose what we need18:18
Pali$ ll /sys/class/input/input*/capabilities/ff18:18
Palifreemangordon: that match is really easy ^^^18:18
freemangordonhmm, no there is evdev ioctl for that18:19
freemangordonas we can get the supported buttons as well18:19
Wizzupgetting the name is EVIOCGNAME18:22
freemangordonWizzup: seems you know evdev, could you write a function that gets "/dev/input/eventX", event types and buttons to match and returns fd if those match?18:23
WizzupC, right?18:24
Wizzupwill do18:24
Wizzupdo you want to match against something hardcoded?18:25
Wizzup(I guess so?)18:25
freemangordonWizzup: BTW, can we disable some of the keys via evdev interface?18:25
freemangordonno hadcoded18:25
freemangordona parameters18:25
freemangordonlike match("/dev/input/event1", EV_KEY18:26
Wizzupinput devices are immutable, what can be done is grabbing the device (being the sole program to get the events), making a new input device, and filtering certain events18:26
Wizzupmatch(file, EV_KEY, KEY_A) ?18:26
freemangordonbut 2 and 3 parameters should be arrays IMO18:26
freemangordonor somesuch18:27
freemangordonto be able to match both EV_SW and EV_KEY, for example18:27
freemangordonwith apprpriate masks for keys and switches18:27
WizzupI would say that param 2 should not be - since EV_SW cannot have KEY_A for example18:27
Wizzupwell, I guess that is possible though18:27
Wizzupjust needs to be well defined/clear :)18:27
*** trumee has quit IRC18:28
freemangordonhaveing integer array as a second and third parameter should do the job18:28
freemangordon{EV_KEY, EV_SW, -1}18:28
freemangordonand array of integer arrays for the third18:28
freemangordon{{KEY_A, KEY_B, -1},{SW_KEYPAD_SLIDE,  SW_CAMERA_LENS_COVER, -1}};18:29
freemangordonWizzup: ^^^18:30
*** trumee has joined #maemo18:35
Wizzupwill need like 30 mins.18:37
freemangordonno hurry18:38
*** trumee has quit IRC18:42
*** Vajb has quit IRC18:49
*** trumee has joined #maemo18:54
Palifreemangordon, Wizzup: there is sysfs entry for disabling: /sys/class/input/input*/device/disabled_keys /sys/class/input/input*/device/disabled_switches18:55
freemangordonPali: I know18:55
freemangordonthe point is that it would have been easier if we could do it via evdev interface18:56
Palibut this is specific for gpio-keys.ko driver :-(18:56
WizzupPali: ah, tmyk18:57
Wizzupah, right.18:57
freemangordonPali: yes, exactly18:57
*** ced117 has quit IRC18:58
Paligpio-keys.ko support it only via sysfs18:58
*** ced117 has joined #maemo19:12
*** trumee has quit IRC19:12
*** trumee has joined #maemo19:15
*** realitygaps has quit IRC19:22
*** realitygaps has joined #maemo19:22
*** realitygaps has joined #maemo19:22
Wizzupfreemangordon: something like this19:26
Wizzupthe defines at the top of the function are taken from evtest19:26
Wizzupah - there is a bit more I have to clean up19:30
Wizzupstray call that is not required19:30
Wizzup should do it19:33
*** at1as has joined #maemo19:41
Wizzupremoved extra q = 0; ->
Wizzupthe NULL is not required in the key_keys arg20:00
*** louisdk has quit IRC20:01
*** louisdk has joined #maemo20:08
*** sparetire_ has joined #maemo20:18
*** rosseaux has joined #maemo20:25
DocScrutinizer05chem|st: xes: warfare: why does tmo block *reading* visitors?20:37
DocScrutinizer05>>Sorry, it seems that you are using an IP address or a proxy that is listed in the forum anti spam blacklist.<<20:37
DocScrutinizer05how would a visitor spam the forum?20:37
DocScrutinizer05I haven't checked this yet (I can't tbh, wrong unblocked IP) but reports from Hellekin suggest the forum spits out that error message quoted above for visitors simply trying to read an arbitrary post like
*** Vajb has joined #maemo20:45
*** ced117 has quit IRC20:47
*** trumee has quit IRC21:02
*** SmilyOrg has quit IRC21:02
*** Smily has joined #maemo21:03
*** trumee has joined #maemo21:04
*** Smily has quit IRC21:05
*** Roth has joined #maemo21:08
*** raandoom has joined #maemo21:08
*** Smily has joined #maemo21:08
freemangordonWizzup: thanks; will look at later21:14
Wizzupno rush21:15
DocScrutinizer05xes: warfare: chem|st: I'd think DoS by unregistered visitors would get blocked by traffic shaping or fail2ban, access to login page by fail2ban or vbulletin internal means when number of failed tries per time from one IP fail, and only access to registration page needs spam-list blocking. No?21:23
DocScrutinizer05"sorry, Tor users are not allowed to *read* this forum" is silly21:31
DocScrutinizer05I can see how Tor is prolly used by spammers to write posts, but it is also used by the most privacy and security aware legit users to _read_ tmo. The latter shouldn't get blocked21:36
DocScrutinizer05no read access should get blocked, only write access21:37
DocScrutinizer05(except in case of [D]DoS)21:38
*** pozitron has joined #maemo21:40
DocScrutinizer05hmm, possibly another 'user' (actually bot) used same Tor exit node to brute-force try to register to tmo. So the only feasible way to block this is to ban the tor node IP, assuming our infra blocks on firewall level this would result in such effect21:43
*** arossdotme has quit IRC21:47
bencoh+1 for read-access21:51
*** louisdk has quit IRC21:51
*** louisdk has joined #maemo21:55
*** realitygaps has quit IRC21:57
*** realitygaps has joined #maemo21:57
*** realitygaps has joined #maemo21:57
*** pozitron has quit IRC21:58
*** Venusaur has quit IRC22:00
*** NIN101 has quit IRC22:01
*** florian has quit IRC22:02
*** NIN101 has joined #maemo22:03
*** arossdotme has joined #maemo22:06
Palifreemangordon: new version of module-init-tools is in cssu-devel, now modprobe should take params also from kernel cmdline22:06
*** florian has joined #maemo22:11
*** FlameReaper-PC has quit IRC22:12
*** Venusaur has joined #maemo22:15
*** peetah has quit IRC22:29
*** peetah has joined #maemo22:32
DocScrutinizer05warfare: xes: assuming IP filtering is done on firewall, we need a "RPC-channel" from tmo engine to the firewall to add 'offender IPs'22:34
DocScrutinizer05tmo engine should only blacklist actual offenders, not do a preemptive block of whole RMBs22:36
DocScrutinizer05IOW the attack detection must run on tmo, only the teckling of tagged offenders may happen on firewall. And FW should automatically clean out expired IPs from block table after some relatively short period (24h?)22:38
*** LauRoman has joined #maemo22:43
*** krnlyng has quit IRC22:45
freemangordonPali: good22:58
warfareDocScrutinizer05: The IP Filter is implemented in Apache and pulls a stop-forum-spam list. Only blocking registration and/or posting might pose a bit difficult.22:58
freemangordonPali: coiuld you upgrade to -rc7, to see if net bug is still there? If it is, I'll try to bisect22:59
*** krnlyng has joined #maemo22:59
DocScrutinizer05warfare: I see22:59
DocScrutinizer05warfare: a tad cumbersome for innocent users only wanting to read a post and getting rejected just because they have the wrong IP23:00
warfareDocScrutinizer05: yes, definitely. Maybe there is some anti-spam support in vbulletin.23:01
DocScrutinizer05maybe we need a read-only mirror without filtering ;-)23:01
*** raandoom has quit IRC23:19
*** Roth has quit IRC23:20
*** ced117 has joined #maemo23:37
*** louisdk has quit IRC23:55

Generated by 2.15.1 by Marius Gedminas - find it at!