| *** justingo has joined #maemo | 00:02 | |
| *** justingo has quit IRC | 00:03 | |
| *** justingo has joined #maemo | 00:04 | |
| *** justingo has quit IRC | 00:05 | |
| *** justingo has joined #maemo | 00:05 | |
| Pali | freemangordon: you need to compile gpio-keys.ko | 00:07 |
|---|---|---|
| Pali | and then via /dev/input/event<num> ask for switch status | 00:07 |
| Pali | currently gpio-keys.ko is disabled in linux-n900 tree CONFIG_KEYBOARD_GPIO=m is needed for it | 00:08 |
| *** justingo has quit IRC | 00:09 | |
| freemangordon | Pali: and how do you distinguish between various switch types? is there interface for it? | 00:11 |
| freemangordon | Pali: and what "ask" means? poll()? | 00:11 |
| Pali | freemangordon: yes, each switch has its own "code" | 00:11 |
| freemangordon | code? | 00:11 |
| Pali | like key press | 00:11 |
| Pali | every key has its own code | 00:12 |
| Pali | keypad_slide --> gpios = <&gpio3 7 GPIO_ACTIVE_LOW>; /* 71 */ --> linux,code = <0x0a>; /* SW_KEYPAD_SLIDE */ | 00:12 |
| Pali | all is defined in DTS | 00:13 |
| freemangordon | oh, so we open all the stuff in /dev/input and wait for KEY_SLIDE on all of the descriptors? | 00:13 |
| Pali | not all stuff in /dev/input | 00:13 |
| Pali | just one device which has that name gpio-keys | 00:13 |
| freemangordon | where is that "name" defined? in /sys/input/devices? | 00:14 |
| *** justingo has joined #maemo | 00:15 | |
| jonwil | Pali: Is the intent that upstream kernel works with stock bme or will upstream kernel need your bme replacement? | 00:21 |
| jonwil | actually, it doesn't matter :) | 00:23 |
| freemangordon | jonwil: it needs bme-replacement | 00:23 |
| jonwil | ok | 00:23 |
| jon_y | are we getting kernel 4.x yet? :) | 00:26 |
| Pali | freemangordon: name is defined in DTS too | 00:27 |
| Pali | jonwil: upstream kernel works with bme replacment | 00:28 |
| Pali | *already* | 00:28 |
| *** robink has quit IRC | 00:39 | |
| *** robink_ has joined #maemo | 00:42 | |
| *** futpib_ has quit IRC | 00:45 | |
| *** realitygaps has quit IRC | 00:47 | |
| *** realitygaps has joined #maemo | 00:50 | |
| *** realitygaps has joined #maemo | 00:50 | |
| *** justingo has quit IRC | 00:54 | |
| DocScrutinizer05 | freemangordon: ((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 pruning | 01:03 |
| Wizzup | having an upstream kernel is great for many reasons | 01:04 |
| Wizzup | for one - grsecurity :) | 01:04 |
| DocScrutinizer05 | well, having an upstream jkernel doesn't mean you need *all* of that stuff, most is cruft for your particular device | 01:05 |
| Wizzup | I 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 |
| Wizzup | Either way, I'm happy with the work that seems to be done! | 01:05 |
| *** erlehmann has joined #maemo | 01:06 | |
| DocScrutinizer05 | because such generic stuff costs storage and memory and runtime | 01:06 |
| *** Pali has quit IRC | 01:07 | |
| DocScrutinizer05 | e.g. for hostmode we had to kick out a shitload of cruft that got in the way with USB enum and hubs and whatnot | 01:07 |
| *** erlehmann has quit IRC | 01:08 | |
| DocScrutinizer05 | but I don't want to argue, I know I won't make a point against 99% of devels | 01:08 |
| DocScrutinizer05 | I 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 never | 01:09 |
| Wizzup | which is dreadful for security and interoperability | 01:10 |
| Wizzup | I don't think some generic path resolve will use that much mem/storage/runtimecpu | 01:10 |
| DocScrutinizer05 | err why? as long as upstream patches apply to your local branch? | 01:10 |
| Wizzup | because it is a PITA to maintain | 01:10 |
| jonwil | Pali: 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 |
| Wizzup | keeping track of all the security patches, let alone bug fixes | 01:11 |
| Wizzup | jonwil: he left | 01:11 |
| jonwil | oh ok | 01:11 |
| DocScrutinizer05 | tzz, that's the "I'm too lazy" argument that naver resulted in technically optimized solutions | 01:11 |
| Wizzup | jonwil: maybe the wiki article he mentioned helps (I guess you saw it already) | 01:11 |
| jonwil | nope, that doesn't help so much | 01:11 |
| DocScrutinizer05 | as long as you do smart 'proprietary' patches to your branch, upstream security and maintenance patches should apply without any conflict | 01:13 |
| Wizzup | but why bother if you can just use the latest version? why spend many hours on something that is already taken care of | 01:13 |
| Wizzup | anyway, I also don't want to argue :) | 01:13 |
| DocScrutinizer05 | because of the headache freemangordon has with "what do we do with changing/differing GPIO numbers on same platform" | 01:16 |
| DocScrutinizer05 | for example | 01:16 |
| DocScrutinizer05 | embedded is *way* more different from platform to platform than your average PC differs between Dell and younameit | 01:17 |
| DocScrutinizer05 | and the complexity of those differences typically is of the class that has no proper means to deal with it at all in a generic kernel | 01:18 |
| kerio | my embedded ARM home server runs mainline linux | 01:18 |
| Wizzup | kerio: mine too :) | 01:18 |
| Wizzup | my arm laptop too | 01:18 |
| kerio | and it's awful | 01:19 |
| kerio | because it's not bsd | 01:19 |
| Wizzup | lol. | 01:19 |
| DocScrutinizer05 | kerio: then prolly because some poor sods upstreamed the patches needed to make the linux run on that platform | 01:19 |
| kerio | indeed! | 01:19 |
| kerio | maemo has *two* poor sods | 01:19 |
| Wizzup | DocScrutinizer05: what's with the hate? Why isn't it awesome that we can use stuff like btrfs on ARM home servers? | 01:19 |
| DocScrutinizer05 | huh? | 01:19 |
| Wizzup | Some things takes so much work to backport to older versions, when you can simple use the latest LTS / mainline version | 01:19 |
| DocScrutinizer05 | you totally lost me | 01:20 |
| Wizzup | poor sods -> great people | 01:20 |
| Wizzup | :) | 01:20 |
| Wizzup | is my point mostly | 01:20 |
| Wizzup | guess I misunderstood | 01:20 |
| kerio | DocScrutinizer05: being able to run mainline means that you get access to new features | 01:20 |
| kerio | and they can be good | 01:20 |
| DocScrutinizer05 | so what? | 01:20 |
| Wizzup | That can often means better performance, lower memory usage, more bug fixes, etc, etc. | 01:21 |
| Wizzup | Better crypto, other things relevant to embedded | 01:21 |
| DocScrutinizer05 | in 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 voila | 01:22 |
| Wizzup | I still do that for all my machines | 01:22 |
| Wizzup | And you can also do that for the N900 with mainline/upstream | 01:22 |
| kerio | DocScrutinizer05: that's not at all what "mainline kernel" means | 01:22 |
| kerio | or, rather | 01:23 |
| kerio | that's not in contradiction with | 01:23 |
| DocScrutinizer05 | it'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 upstreamed | 01:24 |
| Wizzup | there are quite some arm devices where everything is upstreamed :) | 01:24 |
| DocScrutinizer05 | and you might want to prune that branch to kick out obviously cruft items | 01:24 |
| Wizzup | I think for the n900, where the bits are not upstreamed, they are in some branch. Like with amd64 platform drivers | 01:25 |
| DocScrutinizer05 | ARM doesn't need PCI-support | 01:25 |
| DocScrutinizer05 | nor fan sensor support | 01:25 |
| DocScrutinizer05 | nor weird AMD graka drivers | 01:25 |
| Wizzup | Jetson TK1 has PCI slots | 01:26 |
| Wizzup | TX1 has them too | 01:26 |
| Wizzup | and the ARM servers have them too | 01:26 |
| kerio | :o | 01:26 |
| DocScrutinizer05 | N900 has _not_ exactly my point | 01:26 |
| Wizzup | You said "ARM" :) | 01:26 |
| kerio | neo900 feature request: pci express | 01:26 |
| *** lobito1 has quit IRC | 01:26 | |
| DocScrutinizer05 | :-P | 01:26 |
| Wizzup | merlijn@deepwater ~ $ sudo zgrep CONFIG_PCI /proc/config.gz | 01:26 |
| Wizzup | # CONFIG_PCI is not set | 01:26 |
| Wizzup | ^arm machine | 01:27 |
| Wizzup | not hard to disable :) | 01:27 |
| DocScrutinizer05 | ok, and what do you do when it starts to be hard or impossible? | 01:27 |
| kerio | you file a bug | 01:28 |
| kerio | it's linux, not systemd | 01:28 |
| Wizzup | gnu/linux in the case of the n900 | 01:28 |
| * Wizzup hides | 01:28 | |
| DocScrutinizer05 | like with lis302 driver which is completely brainfucked in upstream, and will cut through your battery in no time | 01:28 |
| kerio | the maintainer yells at the other devs, not at the users | 01:28 |
| kerio | Wizzup: no, "linux" is quite specifically correct here | 01:28 |
| Wizzup | kerio: I realised ;-) | 01:29 |
| Wizzup | I just felt trolly | 01:29 |
| Wizzup | I'll go and hit the sack :) | 01:29 |
| *** lobito has joined #maemo | 01:31 | |
| freemangordon | DocScrutinizer05: reasons are technical, I give a shit about politics and you know it :) | 01:44 |
| freemangordon | very similar to what Wizzup said - the cost of maintenance and platform independence | 01:45 |
| freemangordon | why we should have HW specific stuff if we can skip it | 01:47 |
| freemangordon | for 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 API | 01:48 |
| freemangordon | or what Pali said ^^^ - using generic /dev/input interface with board file providing the HW specific settings | 01:49 |
| freemangordon | DocScrutinizer05: also, believe it or not, but upstream kernel runs waaay faster that stock, when it works ofc | 01:50 |
| freemangordon | we have things like neon-optimized functions, RCU, lots of optimizations, etc, etc | 01:51 |
| freemangordon | I am not thinking N900 or Neo900 here, but Maemo | 01:52 |
| freemangordon | from the POV of the userspace it should not matter what platform it is and whether it is embedded or server | 01:52 |
| freemangordon | also, 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 N900 | 01:54 |
| DocScrutinizer05 | then 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 both | 01:54 |
| freemangordon | but 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 HW | 01:55 |
| DocScrutinizer05 | you can't expect same kernel API on different platforms | 01:55 |
| *** esaym has joined #maemo | 01:55 | |
| freemangordon | why? | 01:55 |
| freemangordon | a switch is a switch, dammit | 01:56 |
| DocScrutinizer05 | because one has a LCD and the other OLED, one a c-ts and the other a r-ts, and so on | 01:56 |
| *** heroux_ has joined #maemo | 01:56 | |
| *** keithzg_ has joined #maemo | 01:56 | |
| freemangordon | ok, lets assume it is harder to do it for complicated HW like TS and camera, but again - a SWITCH? | 01:57 |
| *** stryngs has quit IRC | 01:57 | |
| *** luke-jr_ has joined #maemo | 01:57 | |
| DocScrutinizer05 | and 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 position | 01:58 |
| freemangordon | DocScrutinizer05: ever heard of WOSA/XFS? | 01:58 |
| DocScrutinizer05 | no | 01:58 |
| DocScrutinizer05 | should I? | 01:59 |
| freemangordon | no, https://en.wikipedia.org/wiki/CEN/XFS | 01:59 |
| *** clopez has quit IRC | 02:00 | |
| *** esaym153 has quit IRC | 02:00 | |
| *** heroux has quit IRC | 02:00 | |
| *** auenfx4 has quit IRC | 02:00 | |
| *** keithzg has quit IRC | 02:00 | |
| *** chainsawbike has quit IRC | 02:00 | |
| *** discopig has quit IRC | 02:00 | |
| *** ceene has quit IRC | 02:00 | |
| *** Luke-Jr has quit IRC | 02:00 | |
| *** ceene has joined #maemo | 02:00 | |
| *** smhar has quit IRC | 02:00 | |
| *** mickname has quit IRC | 02:00 | |
| *** inz has quit IRC | 02:00 | |
| *** jrayhawk_ has quit IRC | 02:00 | |
| *** chfoo- has quit IRC | 02:00 | |
| *** juiceme has quit IRC | 02:00 | |
| *** heroux_ is now known as heroux | 02:00 | |
| kerio | freemangordon: now look at what you've done | 02:00 |
| freemangordon | if 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 it | 02:00 |
| *** auenfx4 has joined #maemo | 02:00 | |
| freemangordon | yeah :) | 02:00 |
| *** juiceme has joined #maemo | 02:00 | |
| *** LjL has quit IRC | 02:00 | |
| *** Milhouse has quit IRC | 02:00 | |
| *** inz has joined #maemo | 02:00 | |
| *** chfoo- has joined #maemo | 02:01 | |
| *** chainsawbike has joined #maemo | 02:01 | |
| *** jrayhawk has joined #maemo | 02:01 | |
| *** pozitrono has joined #maemo | 02:01 | |
| *** juiceme is now known as Guest78024 | 02:01 | |
| *** pozitrono has quit IRC | 02:01 | |
| *** LjL has joined #maemo | 02:02 | |
| *** smhar has joined #maemo | 02:02 | |
| *** clopez_ has joined #maemo | 02:02 | |
| DocScrutinizer05 | well, as long as you don't upstream your brilliant unified switch API, it is again a proprietary stuff for your very own hw platform only | 02:02 |
| freemangordon | but, it seems it is already upstreamed, according to Pali and is called gpio-key :) | 02:03 |
| kerio | hardware people talking about software is almost as bad as software people talking about hardware :< | 02:03 |
| DocScrutinizer05 | and don't get me wrong, I *cursed* dbus and HAL and friends to hell for their crappy handling of button/switch events | 02:03 |
| freemangordon | but yeah, as SW switch does not fit into that gpio-switch | 02:04 |
| *** stryngs has joined #maemo | 02:04 | |
| freemangordon | *gpio-key | 02:04 |
| *** stryngs is now known as Guest54554 | 02:04 | |
| freemangordon | but then you have a way to create stuff in /dev/input | 02:04 |
| freemangordon | kerio: neither me nor DocScrutinizer05 are SW only or HW only guys | 02:05 |
| *** mickname has joined #maemo | 02:05 | |
| DocScrutinizer05 | I also think it's insane that mce has to check GPIO57 or whatever to learn if kbd is open or cam trigger pressed | 02:05 |
| DocScrutinizer05 | freemangordon: ack :-D | 02:06 |
| freemangordon | exactly. But this is what happens when you make SW with a particular HW platform in mind | 02:06 |
| freemangordon | I really don't get it why power buttons and volume keys produce KBD events, but lock switch and slider do not | 02:07 |
| freemangordon | in stick kernel that is | 02:08 |
| freemangordon | *stock | 02:08 |
| freemangordon | anyway, getting late here , /me going to have some sleep | 02:08 |
| freemangordon | night guys | 02:08 |
| DocScrutinizer05 | I 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 trigger | 02:09 |
| DocScrutinizer05 | s/devine/define/ | 02:09 |
| infobot | DocScrutinizer05 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-headset | 02:10 |
| DocScrutinizer05 | in a way quite similar to what you do in decent programs to define your audio device | 02:11 |
| freemangordon | no, 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 system | 02:11 |
| freemangordon | anyway, night | 02:12 |
| DocScrutinizer05 | :-) night! | 02:13 |
| DocScrutinizer05 | I always thought that /sys/*/bla/GPIO/* approach was pretty kinky | 02:13 |
| DocScrutinizer05 | nice for hackers who know the device by heart. But a nightmare for everybody else, including userland app devels | 02:14 |
| *** luke-jr_ is now known as Luke-Jr | 02:14 | |
| *** Milhouse has joined #maemo | 02:14 | |
| DocScrutinizer05 | even /dev/input/* is quite obfuscated and messed up | 02:16 |
| DocScrutinizer05 | what 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 |
| DocScrutinizer05 | I don't suggest any busses (dbus) or the like since they introduce too much overhead and jitter and lag | 02:22 |
| DocScrutinizer05 | you don't want to play a electric piano keyboard when it gets interfaced via dbus messages | 02:23 |
| Wizzup | What is obfuscated about /dev/input? | 02:25 |
| DocScrutinizer05 | you 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 there | 02:25 |
| Wizzup | #include <linux/input.h> and go | 02:26 |
| DocScrutinizer05 | Wizzup: http://paste.opensuse.org/50869960 | 02:26 |
| Wizzup | DocScrutinizer05: ls -lsh /dev/input/by-id | 02:27 |
| Wizzup | same for by-path | 02:27 |
| Wizzup | 0 lrwxrwxrwx 1 root root 9 Jan 1 20:53 usb-0d8c_C-Media_USB_Headphone_Set-event-if03 -> ../event4 | 02:27 |
| Wizzup | 0 lrwxrwxrwx 1 root root 9 Jan 1 20:53 usb-Logitech_USB_Optical_Mouse-event-mouse -> ../event1 | 02:27 |
| Wizzup | 0 lrwxrwxrwx 1 root root 9 Jan 1 20:53 usb-Logitech_USB_Optical_Mouse-mouse -> ../mouse0 | 02:27 |
| DocScrutinizer05 | still pretty fuzzy gibberish, but yeah a tad better | 02:27 |
| Wizzup | I used it extensively when messing around with virtual input device creation, forwarding it over the network, remapping | 02:28 |
| Wizzup | was fun | 02:28 |
| Wizzup | the main thing that troubled me were all the KEY_ constants | 02:28 |
| DocScrutinizer05 | http://paste.opensuse.org/41999573 | 02:29 |
| DocScrutinizer05 | it's still almost a miracle (and completely unfeasible) to me to put the 13 buttons of my mouse to any purpose | 02:30 |
| Wizzup | so 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 there | 02:30 |
| Wizzup | DocScrutinizer05: you may be interested in http://hetgrotebos.org/wiki/uinput-mapper | 02:31 |
| DocScrutinizer05 | some 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 two | 02:31 |
| Wizzup | You can achieve exactly that (remapping buttons to other buttoms) | 02:31 |
| Wizzup | buttons* even | 02:31 |
| Wizzup | There is an older/outdated version in maemo repos that I need to update | 02:31 |
| DocScrutinizer05 | prominent example: search key on mouse | 02:32 |
| DocScrutinizer05 | which acts as if it was a kbd key | 02:32 |
| Wizzup | http://hetgrotebos.org/wiki/uinput-mapper/UseCases | 02:32 |
| Wizzup | anyway /me wrote the sw, so it's a bit of a plug but also related :) | 02:33 |
| DocScrutinizer05 | pc-speaker is prolly a jack-insert event | 02:33 |
| Wizzup | if you ever want to mess around with those extra mouse buttons, let me know when it's not 1:30 am :D | 02:33 |
| Wizzup | I thought pc-speaker was almost one of those things that you have to strip from the mobo | 02:33 |
| Wizzup | s/almost/always/ | 02:34 |
| infobot | Wizzup meant: I thought pc-speaker was always one of those things that you have to strip from the mobo | 02:34 |
| Wizzup | the one that generate the annoying terminal bells, making you want to rmmod pcspeaker | 02:34 |
| DocScrutinizer05 | I wish mine did more frequently | 02:35 |
| DocScrutinizer05 | I think the only sw that uses pc-speaker anymore is eagle | 02:35 |
| Wizzup | ttys do too | 02:36 |
| Wizzup | just type ^K (iirc terminal bell) in a tty | 02:36 |
| DocScrutinizer05 | (mess with mousebutton) there's a forward/back button pair I'd love to assign a new hotkey meaning to in KDE | 02:37 |
| DocScrutinizer05 | ^G | 02:38 |
| Wizzup | evtest (and my own input-read) can dump all the keys a node in /dev/input/ exports | 02:38 |
| DocScrutinizer05 | G wie Glocke | 02:38 |
| Wizzup | you can assign the mouse buttons to any key in /usr/include/linux/input.h | 02:38 |
| DocScrutinizer05 | ok, I want them to get assigned to KEY_BACK and KEY_FORWARD, say | 02:42 |
| *** Ras_Older has joined #maemo | 02:44 | |
| DocScrutinizer05 | hmm no evtest | 02:45 |
| Wizzup | so 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 send | 02:45 |
| Wizzup | and kde will automatically pick up the new mouse/keyboard | 02:45 |
| DocScrutinizer05 | that was an easy one, just installed it | 02:45 |
| Wizzup | :) | 02:46 |
| Wizzup | I need to sleep though - happy to help tomorrow | 02:46 |
| Wizzup | or whenever I wake up | 02:46 |
| DocScrutinizer05 | http://paste.opensuse.org/57901578 | 02:49 |
| DocScrutinizer05 | from: evtest --grab by-id/usb-Logitech_Logitech_BT_Mini-Receiver_001F2051A1CA-event-mouse | 02:50 |
| DocScrutinizer05 | Wizzup: 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 |
| DocScrutinizer05 | the damn battery is worn | 02:53 |
| *** xorly has quit IRC | 02:57 | |
| *** florian has quit IRC | 03:03 | |
| *** sq-one has quit IRC | 03:15 | |
| *** robbiethe1st has joined #maemo | 03:27 | |
| *** LauRoman has quit IRC | 03:58 | |
| *** LauRoman|Phone has joined #maemo | 03:58 | |
| *** eMHa_ has joined #maemo | 04:17 | |
| *** eMHa has quit IRC | 04:20 | |
| *** Defiant has quit IRC | 04:41 | |
| *** Defiant has joined #maemo | 04:42 | |
| *** louisdk has quit IRC | 05:17 | |
| *** louisdk has joined #maemo | 05:28 | |
| *** louisdk has quit IRC | 05:46 | |
| *** lobito has quit IRC | 05:58 | |
| *** lobito has joined #maemo | 06:00 | |
| *** DocScrutinizer05 has quit IRC | 06:04 | |
| *** DocScrutinizer05 has joined #maemo | 06:05 | |
| *** louisdk has joined #maemo | 06:17 | |
| *** louisdk has quit IRC | 06:24 | |
| *** Vajb has joined #maemo | 07:30 | |
| *** protem has quit IRC | 07:33 | |
| *** robbiethe1st has quit IRC | 07:45 | |
| *** jonwil has quit IRC | 07:59 | |
| *** vahe has joined #maemo | 08:08 | |
| *** sparetire_ has quit IRC | 08:25 | |
| *** pozitrono has joined #maemo | 09:40 | |
| *** robink_ has quit IRC | 09:50 | |
| *** robink_ has joined #maemo | 09:50 | |
| *** LauRoman|Phone has quit IRC | 09:55 | |
| *** LauRoman has joined #maemo | 10:07 | |
| *** qwazix has quit IRC | 10:33 | |
| *** jonwil has joined #maemo | 10:34 | |
| jonwil | hi | 10:36 |
| brolin_empey | jonwil: ’lo. | 10:50 |
| *** qwazix has joined #maemo | 10:51 | |
| *** pozitrono has quit IRC | 11:10 | |
| *** Pali has joined #maemo | 11:14 | |
| *** Pali has quit IRC | 11:23 | |
| *** Pali has joined #maemo | 11:33 | |
| *** Bono_NL has joined #maemo | 11:36 | |
| *** florian has joined #maemo | 11:41 | |
| *** Bono_NL has quit IRC | 12:07 | |
| *** Bono_NL has joined #maemo | 12:08 | |
| *** futpib_ has joined #maemo | 12:19 | |
| *** realitygaps has quit IRC | 12:21 | |
| *** Bono_NL has quit IRC | 12:22 | |
| *** LauRoman has quit IRC | 12:25 | |
| *** realitygaps has joined #maemo | 12:32 | |
| *** realitygaps has quit IRC | 12:32 | |
| *** realitygaps has joined #maemo | 12:32 | |
| *** ssvb_ has quit IRC | 12:36 | |
| *** ssvb_ has joined #maemo | 12:37 | |
| *** ssvb_ has quit IRC | 12:40 | |
| *** ssvb_ has joined #maemo | 12:40 | |
| *** jonwil has quit IRC | 13:02 | |
| *** realitygaps has quit IRC | 13:02 | |
| *** abdullah has joined #maemo | 13:05 | |
| *** realitygaps has joined #maemo | 13:07 | |
| *** abdullah has quit IRC | 13:19 | |
| *** Vajb has quit IRC | 13:19 | |
| *** Hurrian has quit IRC | 13:20 | |
| *** Hurrian has joined #maemo | 13:23 | |
| *** Hurrian has quit IRC | 13:28 | |
| *** Hurrian has joined #maemo | 13:31 | |
| *** discopig has joined #maemo | 13:35 | |
| *** florian has quit IRC | 13:35 | |
| *** realitygaps has quit IRC | 13:38 | |
| *** realitygaps has joined #maemo | 13:39 | |
| *** realitygaps has joined #maemo | 13:39 | |
| freemangordon | Pali: what about something like http://pastebin.com/TF8ywZAq | 13:53 |
| freemangordon | the only problem is that events are registered with a delay, but I guess this can be fixed | 13:53 |
| Pali | freemangordon: looks good | 13:57 |
| Pali | only one problem is in ALS_PATH_RX51_3x | 13:57 |
| Pali | path via i2c-adapter is not stable | 13:58 |
| freemangordon | yeah, I forgot I touched that one too. But anyway, ^^^ is just POC | 13:58 |
| freemangordon | I know | 13:58 |
| Pali | there should be more stable symlink in /sys somewhere | 13:58 |
| freemangordon | Pali: any clue why events might come delayed? the way mce sets giomonitor? | 13:58 |
| Pali | first check that kernel does not delay them | 13:59 |
| freemangordon | where? | 13:59 |
| Pali | use e.g. program input-events | 13:59 |
| freemangordon | evtest spits them immediately | 13:59 |
| Pali | ok | 13:59 |
| Pali | then it is somewhere in mce.. | 14:00 |
| freemangordon | anyway, have to leave now, will look at the issue later | 14:00 |
| freemangordon | yes, something in mce | 14:00 |
| freemangordon | bb for now | 14:00 |
| Wizzup | How much are they delayed? | 14:00 |
| freemangordon | hard to say, but more than a second | 14:00 |
| freemangordon | also, it is not the same everytime | 14:00 |
| *** Vajb has joined #maemo | 14:16 | |
| *** pharacker has joined #maemo | 14:25 | |
| *** Oksanaa has joined #maemo | 14:31 | |
| *** pharacker has quit IRC | 14:32 | |
| *** xorly has joined #maemo | 14:32 | |
| Oksanaa | I 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 #maemo | 14:49 | |
| *** florian has joined #maemo | 15:03 | |
| DocScrutinizer05 | man apt | 15:04 |
| *** raandoom has joined #maemo | 15:08 | |
| *** realitygaps has quit IRC | 15:15 | |
| *** realitygaps has joined #maemo | 15:16 | |
| *** realitygaps has quit IRC | 15:16 | |
| *** realitygaps has joined #maemo | 15:16 | |
| *** raandoom has quit IRC | 15:22 | |
| *** raandoom has joined #maemo | 15:24 | |
| *** abdullah has joined #maemo | 15:29 | |
| *** abdullah has quit IRC | 15:30 | |
| DocScrutinizer05 | it's of course arguable if those avatar files are really 'config data' | 15:30 |
| kerio | they're not | 15:31 |
| DocScrutinizer05 | but I think the general take on this is "never delete anything from user's home" | 15:31 |
| kerio | the cache should really not be in /home/user though | 15:32 |
| kerio | i guess that storing it in MyDocs becomes complicated, however | 15:32 |
| *** SmilyOrg has joined #maemo | 15:34 | |
| DocScrutinizer05 | how so? | 15:35 |
| kerio | MyDocs gets unmounted at the user's will | 15:35 |
| DocScrutinizer05 | yeah | 15:35 |
| kerio | stupid decisions all around, really | 15:36 |
| DocScrutinizer05 | well, that's the sort of compromises you need to do when you got only 240MB of / | 15:36 |
| *** Djgio07 has joined #maemo | 15:36 | |
| Djgio07 | HI | 15:36 |
| DocScrutinizer05 | though ~optification is really a headache | 15:37 |
| *** Smily has quit IRC | 15:37 | |
| *** Djgio07 has left #maemo | 15:38 | |
| DocScrutinizer05 | when the avatar data is no user's config data then it belongs into /opt | 15:38 |
| DocScrutinizer05 | at least on a genuine maemo5 system | 15:39 |
| *** louisdk has quit IRC | 15:39 | |
| DocScrutinizer05 | and yes, it should get cleaned out then | 15:39 |
| DocScrutinizer05 | "forgot to clear the cache" sounds like a common mistake | 15:39 |
| DocScrutinizer05 | or at your discretion s/cache/tmp/ | 15:41 |
| *** SmilybOrg has joined #maemo | 15:47 | |
| *** SmilyOrg has quit IRC | 15:51 | |
| *** FlameReaper-PC has joined #maemo | 15:51 | |
| *** SmilyOrg has joined #maemo | 15:53 | |
| *** realitygaps has quit IRC | 15:55 | |
| *** realitygaps has joined #maemo | 15:56 | |
| *** realitygaps has joined #maemo | 15:56 | |
| *** SmilybOrg has quit IRC | 15:56 | |
| KotCzarny | one another thing to consider, with generic inputs/gpio, one could try redefining other button/event source (to unlock the screen for example) | 15:56 |
| KotCzarny | or to redefine depending what is running etc | 15:57 |
| KotCzarny | with hardcoded settings there is no such flexibility | 15:57 |
| *** raandoom has quit IRC | 16:05 | |
| *** raandoom has joined #maemo | 16:06 | |
| *** louisdk has joined #maemo | 16:08 | |
| *** krnlyng has quit IRC | 16:13 | |
| *** totalizator has quit IRC | 16:13 | |
| *** totalizator has joined #maemo | 16:14 | |
| *** krnlyng has joined #maemo | 16:14 | |
| *** raandoom has quit IRC | 16:15 | |
| *** raandoom has joined #maemo | 16:15 | |
| *** Ongkut has joined #maemo | 16:21 | |
| *** Ongkut has quit IRC | 16:22 | |
| *** Ongkut has joined #maemo | 16:24 | |
| *** Ongkut has quit IRC | 16:24 | |
| *** Oksanaa has quit IRC | 16:37 | |
| freemangordon | KotCzarny: why is that? We can always introduce switch<->functionality mapping file | 16:40 |
| freemangordon | or gconf or whatever | 16:40 |
| Pali | freemangordon: how hard would be to fix dsp driver and include it again into upstream kernel? | 16:47 |
| Pali | you already played with that code, so maybe you could know... | 16:47 |
| *** trumee has quit IRC | 16:52 | |
| *** trumee has joined #maemo | 16:53 | |
| freemangordon | Pali: they want remoteproc driver. and that wouldn;t be easy | 16:54 |
| freemangordon | i'll need remoteproc coff fw loader and who knows what else | 16:54 |
| freemangordon | *it'll | 16:54 |
| *** Vajb has quit IRC | 16:58 | |
| *** trumee has quit IRC | 17:03 | |
| *** trumee has joined #maemo | 17:04 | |
| *** Vajb has joined #maemo | 17:09 | |
| *** trumee has quit IRC | 17:13 | |
| *** trumee has joined #maemo | 17:20 | |
| Pali | freemangordon: what is remoteproc? | 17:28 |
| freemangordon | Pali: https://www.kernel.org/doc/Documentation/remoteproc.txt | 17:28 |
| Pali | ufff | 17:31 |
| *** realitygaps has quit IRC | 17:32 | |
| Pali | now last version of tidspbridge cannot be compiled anymore (on uptream kernel)... | 17:32 |
| freemangordon | :( | 17:33 |
| *** realitygaps has joined #maemo | 17:36 | |
| *** realitygaps has quit IRC | 17:36 | |
| *** realitygaps has joined #maemo | 17:36 | |
| Pali | in old TODO for tidspbridge is nothing about remoteproc | 17:36 |
| Pali | there is just: DOFF binary loader: consider pushing to user space | 17:37 |
| Pali | only *consider* | 17:37 |
| *** ced117 has quit IRC | 17:49 | |
| freemangordon | Pali: 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 instant | 18:01 |
| Pali | freemangordon: ok | 18:02 |
| *** raandoom has quit IRC | 18:03 | |
| *** ced117 has joined #maemo | 18:05 | |
| freemangordon | Pali: https://github.com/community-ssu/mce/commit/a3f25c56d7f57af5fc5a9c4c375b0db624f70b53 | 18:07 |
| Pali | ok | 18:09 |
| Pali | now I'm looking at mce/modules/vibrator.c and this code is not compatible with upstrem kernel too... | 18:10 |
| Pali | path /sys/class/i2c-adapter/i2c-1/1-0048/twl4030_vibra/pulse does not exist | 18:10 |
| freemangordon | vibrator is exported via evdev as well | 18:10 |
| Pali | looks like that upstream kernel export twl4030 via input layer too! | 18:10 |
| Pali | and twl4030-vibra is registered under audio device | 18:11 |
| freemangordon | just a second do boot | 18:12 |
| freemangordon | Pali: http://pastebin.com/itKGCpMK | 18:15 |
| Pali | EV_FF | 18:15 |
| freemangordon | yes | 18:15 |
| freemangordon | force-feedback | 18:15 |
| Pali | but problem is that event5 name is not stable | 18:16 |
| freemangordon | so what? | 18:16 |
| Wizzup | use by-id or by-path | 18:16 |
| freemangordon | no by-id | 18:16 |
| freemangordon | :) | 18:16 |
| Wizzup | Or is that not available? | 18:16 |
| Wizzup | Yeah, that | 18:16 |
| Pali | need to match against "Input device name" (which is "twl4030:vibrator") | 18:16 |
| Wizzup | Pali: ls /dev/input/by-id :) | 18:16 |
| freemangordon | Pali: we can add another class | 18:17 |
| Pali | or maybe just "*:vibrator" | 18:17 |
| freemangordon | the same way I did for switches | 18:17 |
| freemangordon | Pali: no, we'd rather mach on EV_FF | 18:17 |
| freemangordon | *match | 18:17 |
| freemangordon | instead of a name | 18:17 |
| freemangordon | I was thinking the same for gpio-keys | 18:17 |
| Pali | Wizzup: no by-id in Maemo :-( | 18:17 |
| Pali | freemangordon: yes, match against EV_FF could work too | 18:18 |
| freemangordon | to parse supported keys/switches and to choose what we need | 18:18 |
| Pali | $ ll /sys/class/input/input*/capabilities/ff | 18:18 |
| Pali | freemangordon: that match is really easy ^^^ | 18:18 |
| freemangordon | hmm, no there is evdev ioctl for that | 18:19 |
| Pali | ok | 18:19 |
| freemangordon | as we can get the supported buttons as well | 18:19 |
| Wizzup | getting the name is EVIOCGNAME | 18:22 |
| freemangordon | Wizzup: 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 |
| Wizzup | yes | 18:24 |
| freemangordon | great | 18:24 |
| Wizzup | C, right? | 18:24 |
| freemangordon | yep | 18:24 |
| Wizzup | will do | 18:24 |
| freemangordon | thanks! | 18:24 |
| Wizzup | do you want to match against something hardcoded? | 18:25 |
| Wizzup | (I guess so?) | 18:25 |
| freemangordon | Wizzup: BTW, can we disable some of the keys via evdev interface? | 18:25 |
| freemangordon | no hadcoded | 18:25 |
| freemangordon | a parameters | 18:25 |
| freemangordon | like match("/dev/input/event1", EV_KEY | 18:26 |
| Wizzup | input 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 events | 18:26 |
| freemangordon | oops | 18:26 |
| freemangordon | ... | 18:26 |
| Wizzup | match(file, EV_KEY, KEY_A) ? | 18:26 |
| freemangordon | yes | 18:26 |
| Wizzup | sure | 18:26 |
| freemangordon | but 2 and 3 parameters should be arrays IMO | 18:26 |
| freemangordon | or somesuch | 18:27 |
| Wizzup | ack | 18:27 |
| freemangordon | to be able to match both EV_SW and EV_KEY, for example | 18:27 |
| freemangordon | with apprpriate masks for keys and switches | 18:27 |
| Wizzup | I would say that param 2 should not be - since EV_SW cannot have KEY_A for example | 18:27 |
| Wizzup | well, I guess that is possible though | 18:27 |
| Wizzup | just needs to be well defined/clear :) | 18:27 |
| *** trumee has quit IRC | 18:28 | |
| freemangordon | haveing integer array as a second and third parameter should do the job | 18:28 |
| Wizzup | ack. | 18:28 |
| freemangordon | {EV_KEY, EV_SW, -1} | 18:28 |
| freemangordon | and array of integer arrays for the third | 18:28 |
| freemangordon | {{KEY_A, KEY_B, -1},{SW_KEYPAD_SLIDE, SW_CAMERA_LENS_COVER, -1}}; | 18:29 |
| freemangordon | Wizzup: ^^^ | 18:30 |
| Wizzup | Ack | 18:32 |
| *** trumee has joined #maemo | 18:35 | |
| Wizzup | will need like 30 mins. | 18:37 |
| freemangordon | no hurry | 18:38 |
| *** trumee has quit IRC | 18:42 | |
| *** Vajb has quit IRC | 18:49 | |
| *** trumee has joined #maemo | 18:54 | |
| Pali | freemangordon, Wizzup: there is sysfs entry for disabling: /sys/class/input/input*/device/disabled_keys /sys/class/input/input*/device/disabled_switches | 18:55 |
| freemangordon | Pali: I know | 18:55 |
| freemangordon | the point is that it would have been easier if we could do it via evdev interface | 18:56 |
| Pali | but this is specific for gpio-keys.ko driver :-( | 18:56 |
| Wizzup | Pali: ah, tmyk | 18:57 |
| Wizzup | ah, right. | 18:57 |
| freemangordon | Pali: yes, exactly | 18:57 |
| *** ced117 has quit IRC | 18:58 | |
| Pali | gpio-keys.ko support it only via sysfs | 18:58 |
| Pali | https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/input/keyboard/gpio_keys.c#n58 | 18:59 |
| freemangordon | yeah | 19:02 |
| *** ced117 has joined #maemo | 19:12 | |
| *** trumee has quit IRC | 19:12 | |
| *** trumee has joined #maemo | 19:15 | |
| *** realitygaps has quit IRC | 19:22 | |
| *** realitygaps has joined #maemo | 19:22 | |
| *** realitygaps has joined #maemo | 19:22 | |
| Wizzup | freemangordon: http://sprunge.us/BJdY?c something like this | 19:26 |
| Wizzup | the defines at the top of the function are taken from evtest | 19:26 |
| Wizzup | ah - there is a bit more I have to clean up | 19:30 |
| Wizzup | stray call that is not required | 19:30 |
| Wizzup | http://sprunge.us/baKa?c should do it | 19:33 |
| *** at1as has joined #maemo | 19:41 | |
| Wizzup | removed extra q = 0; -> http://sprunge.us/ZVfM?c | 19:45 |
| Wizzup | the NULL is not required in the key_keys arg | 20:00 |
| *** louisdk has quit IRC | 20:01 | |
| *** louisdk has joined #maemo | 20:08 | |
| *** sparetire_ has joined #maemo | 20:18 | |
| *** rosseaux has joined #maemo | 20:25 | |
| DocScrutinizer05 | chem|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 |
| DocScrutinizer05 | how would a visitor spam the forum? | 20:37 |
| DocScrutinizer05 | I 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 http://talk.maemo.org/showthread.php?p=1492838 | 20:40 |
| *** Vajb has joined #maemo | 20:45 | |
| *** ced117 has quit IRC | 20:47 | |
| *** trumee has quit IRC | 21:02 | |
| *** SmilyOrg has quit IRC | 21:02 | |
| *** Smily has joined #maemo | 21:03 | |
| *** trumee has joined #maemo | 21:04 | |
| *** Smily has quit IRC | 21:05 | |
| *** Roth has joined #maemo | 21:08 | |
| *** raandoom has joined #maemo | 21:08 | |
| *** Smily has joined #maemo | 21:08 | |
| freemangordon | Wizzup: thanks; will look at later | 21:14 |
| Wizzup | no rush | 21:15 |
| DocScrutinizer05 | xes: 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 silly | 21:31 |
| DocScrutinizer05 | I 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 blocked | 21:36 |
| DocScrutinizer05 | no read access should get blocked, only write access | 21:37 |
| DocScrutinizer05 | (except in case of [D]DoS) | 21:38 |
| *** pozitron has joined #maemo | 21:40 | |
| DocScrutinizer05 | hmm, 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 effect | 21:43 |
| *** arossdotme has quit IRC | 21:47 | |
| bencoh | +1 for read-access | 21:51 |
| *** louisdk has quit IRC | 21:51 | |
| *** louisdk has joined #maemo | 21:55 | |
| *** realitygaps has quit IRC | 21:57 | |
| *** realitygaps has joined #maemo | 21:57 | |
| *** realitygaps has joined #maemo | 21:57 | |
| *** pozitron has quit IRC | 21:58 | |
| *** Venusaur has quit IRC | 22:00 | |
| *** NIN101 has quit IRC | 22:01 | |
| *** florian has quit IRC | 22:02 | |
| *** NIN101 has joined #maemo | 22:03 | |
| *** arossdotme has joined #maemo | 22:06 | |
| Pali | freemangordon: new version of module-init-tools is in cssu-devel, now modprobe should take params also from kernel cmdline | 22:06 |
| *** florian has joined #maemo | 22:11 | |
| *** FlameReaper-PC has quit IRC | 22:12 | |
| *** Venusaur has joined #maemo | 22:15 | |
| *** peetah has quit IRC | 22:29 | |
| *** peetah has joined #maemo | 22:32 | |
| DocScrutinizer05 | warfare: 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 |
| DocScrutinizer05 | tmo engine should only blacklist actual offenders, not do a preemptive block of whole RMBs | 22:36 |
| DocScrutinizer05 | IOW 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 #maemo | 22:43 | |
| *** krnlyng has quit IRC | 22:45 | |
| freemangordon | Pali: good | 22:58 |
| warfare | DocScrutinizer05: 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 |
| freemangordon | Pali: coiuld you upgrade to -rc7, to see if net bug is still there? If it is, I'll try to bisect | 22:59 |
| *** krnlyng has joined #maemo | 22:59 | |
| DocScrutinizer05 | warfare: I see | 22:59 |
| DocScrutinizer05 | warfare: a tad cumbersome for innocent users only wanting to read a post and getting rejected just because they have the wrong IP | 23:00 |
| warfare | DocScrutinizer05: yes, definitely. Maybe there is some anti-spam support in vbulletin. | 23:01 |
| DocScrutinizer05 | maybe we need a read-only mirror without filtering ;-) | 23:01 |
| *** raandoom has quit IRC | 23:19 | |
| *** Roth has quit IRC | 23:20 | |
| *** ced117 has joined #maemo | 23:37 | |
| *** louisdk has quit IRC | 23:55 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!