| 00:00.30 | *** join/#maemo ceene (~ceene@138.4.36.7) |
| 00:00.37 | kerio | freemangordon: now look at what you've done |
| 00:00.37 | 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 |
| 00:00.40 | *** join/#maemo auenfx4 (David@120.155.97.223) |
| 00:00.43 | freemangordon | yeah :) |
| 00:00.44 | *** join/#maemo juiceme (~juice@cerebro.liukuma.net) |
| 00:00.57 | *** join/#maemo inz (inz@inz.fi) |
| 00:01.03 | *** join/#maemo chfoo- (~chfooZnc@nullhound.fart.website) |
| 00:01.03 | *** join/#maemo chainsawbike (~chainsawb@unaffiliated/chainsawbike) |
| 00:01.31 | *** join/#maemo jrayhawk (~jrayhawk@unaffiliated/jrayhawk) |
| 00:01.36 | *** join/#maemo pozitrono (~nu@tor-exit2-readme.puckey.org) |
| 00:02.03 | *** join/#maemo LjL (~ljl@unaffiliated/ljl) |
| 00:02.14 | *** join/#maemo smhar (~salman@178.132.44.178) |
| 00:02.21 | *** join/#maemo clopez_ (~tau@neutrino.es) |
| 00:02.41 | 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 |
| 00:03.24 | freemangordon | but, it seems it is already upstreamed, according to Pali and is called gpio-key :) |
| 00:03.46 | kerio | hardware people talking about software is almost as bad as software people talking about hardware :< |
| 00:03.47 | DocScrutinizer05 | and don't get me wrong, I *cursed* dbus and HAL and friends to hell for their crappy handling of button/switch events |
| 00:04.11 | freemangordon | but yeah, as SW switch does not fit into that gpio-switch |
| 00:04.11 | *** join/#maemo stryngs (~stryngs@cloud.ethicalreporting.org) |
| 00:04.22 | freemangordon | *gpio-key |
| 00:04.40 | freemangordon | but then you have a way to create stuff in /dev/input |
| 00:05.20 | freemangordon | kerio: neither me nor DocScrutinizer05 are SW only or HW only guys |
| 00:05.28 | *** join/#maemo mickname (~mickname@low6.kyla.fi) |
| 00:05.39 | 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 |
| 00:06.06 | DocScrutinizer05 | freemangordon: ack :-D |
| 00:06.23 | freemangordon | exactly. But this is what happens when you make SW with a particular HW platform in mind |
| 00:07.53 | freemangordon | I really don't get it why power buttons and volume keys produce KBD events, but lock switch and slider do not |
| 00:08.03 | freemangordon | in stick kernel that is |
| 00:08.07 | freemangordon | *stock |
| 00:08.22 | freemangordon | anyway, getting late here , /me going to have some sleep |
| 00:08.27 | freemangordon | night guys |
| 00:09.13 | 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 |
| 00:09.27 | DocScrutinizer05 | s/devine/define/ |
| 00:10.27 | DocScrutinizer05 | ...or holdbutton-headset |
| 00:11.25 | DocScrutinizer05 | in a way quite similar to what you do in decent programs to define your audio device |
| 00:11.49 | 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 |
| 00:12.24 | freemangordon | anyway, night |
| 00:13.11 | DocScrutinizer05 | :-) night! |
| 00:13.42 | DocScrutinizer05 | I always thought that /sys/*/bla/GPIO/* approach was pretty kinky |
| 00:14.21 | DocScrutinizer05 | nice for hackers who know the device by heart. But a nightmare for everybody else, including userland app devels |
| 00:14.34 | *** join/#maemo Milhouse (~Milhouse@kodi/staff/milhouse) |
| 00:16.25 | DocScrutinizer05 | even /dev/input/* is quite obfuscated and messed up |
| 00:20.35 | 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" |
| 00:22.11 | DocScrutinizer05 | I don't suggest any busses (dbus) or the like since they introduce too much overhead and jitter and lag |
| 00:23.11 | DocScrutinizer05 | you don't want to play a electric piano keyboard when it gets interfaced via dbus messages |
| 00:25.41 | Wizzup | What is obfuscated about /dev/input? |
| 00:25.48 | 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 |
| 00:26.17 | Wizzup | #include <linux/input.h> and go |
| 00:26.44 | DocScrutinizer05 | Wizzup: http://paste.opensuse.org/50869960 |
| 00:27.05 | Wizzup | DocScrutinizer05: ls -lsh /dev/input/by-id |
| 00:27.11 | Wizzup | same for by-path |
| 00:27.28 | Wizzup | 0 lrwxrwxrwx 1 root root 9 Jan 1 20:53 usb-0d8c_C-Media_USB_Headphone_Set-event-if03 -> ../event4 |
| 00:27.31 | Wizzup | 0 lrwxrwxrwx 1 root root 9 Jan 1 20:53 usb-Logitech_USB_Optical_Mouse-event-mouse -> ../event1 |
| 00:27.34 | Wizzup | 0 lrwxrwxrwx 1 root root 9 Jan 1 20:53 usb-Logitech_USB_Optical_Mouse-mouse -> ../mouse0 |
| 00:27.46 | DocScrutinizer05 | still pretty fuzzy gibberish, but yeah a tad better |
| 00:28.17 | Wizzup | I used it extensively when messing around with virtual input device creation, forwarding it over the network, remapping |
| 00:28.20 | Wizzup | was fun |
| 00:28.27 | Wizzup | the main thing that troubled me were all the KEY_ constants |
| 00:29.17 | DocScrutinizer05 | http://paste.opensuse.org/41999573 |
| 00:30.15 | DocScrutinizer05 | it's still almost a miracle (and completely unfeasible) to me to put the 13 buttons of my mouse to any purpose |
| 00:30.53 | 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 |
| 00:31.13 | Wizzup | DocScrutinizer05: you may be interested in http://hetgrotebos.org/wiki/uinput-mapper |
| 00:31.20 | 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 |
| 00:31.25 | Wizzup | You can achieve exactly that (remapping buttons to other buttoms) |
| 00:31.31 | Wizzup | buttons* even |
| 00:31.49 | Wizzup | There is an older/outdated version in maemo repos that I need to update |
| 00:32.24 | DocScrutinizer05 | prominent example: search key on mouse |
| 00:32.34 | DocScrutinizer05 | which acts as if it was a kbd key |
| 00:32.45 | Wizzup | http://hetgrotebos.org/wiki/uinput-mapper/UseCases |
| 00:33.29 | Wizzup | anyway /me wrote the sw, so it's a bit of a plug but also related :) |
| 00:33.41 | DocScrutinizer05 | pc-speaker is prolly a jack-insert event |
| 00:33.44 | Wizzup | if you ever want to mess around with those extra mouse buttons, let me know when it's not 1:30 am :D |
| 00:33.59 | Wizzup | I thought pc-speaker was almost one of those things that you have to strip from the mobo |
| 00:34.04 | Wizzup | s/almost/always/ |
| 00:34.28 | Wizzup | the one that generate the annoying terminal bells, making you want to rmmod pcspeaker |
| 00:35.06 | DocScrutinizer05 | I wish mine did more frequently |
| 00:35.29 | DocScrutinizer05 | I think the only sw that uses pc-speaker anymore is eagle |
| 00:36.25 | Wizzup | ttys do too |
| 00:36.32 | Wizzup | just type ^K (iirc terminal bell) in a tty |
| 00:37.17 | DocScrutinizer05 | (mess with mousebutton) there's a forward/back button pair I'd love to assign a new hotkey meaning to in KDE |
| 00:38.03 | DocScrutinizer05 | ^G |
| 00:38.09 | Wizzup | evtest (and my own input-read) can dump all the keys a node in /dev/input/ exports |
| 00:38.16 | DocScrutinizer05 | G wie Glocke |
| 00:38.46 | Wizzup | you can assign the mouse buttons to any key in /usr/include/linux/input.h |
| 00:42.17 | DocScrutinizer05 | ok, I want them to get assigned to KEY_BACK and KEY_FORWARD, say |
| 00:44.03 | *** join/#maemo Ras_Older (blank@iddqd.fi) |
| 00:45.04 | DocScrutinizer05 | hmm no evtest |
| 00:45.11 | 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 |
| 00:45.32 | Wizzup | and kde will automatically pick up the new mouse/keyboard |
| 00:45.59 | DocScrutinizer05 | that was an easy one, just installed it |
| 00:46.10 | Wizzup | :) |
| 00:46.17 | Wizzup | I need to sleep though - happy to help tomorrow |
| 00:46.20 | Wizzup | or whenever I wake up |
| 00:49.12 | DocScrutinizer05 | http://paste.opensuse.org/57901578 |
| 00:50.51 | DocScrutinizer05 | from: evtest --grab by-id/usb-Logitech_Logitech_BT_Mini-Receiver_001F2051A1CA-event-mouse |
| 00:52.03 | DocScrutinizer05 | Wizzup: you're right, time to chillax (new antileete word) |
| 00:53.19 | DocScrutinizer05 | ...and the mx-revolution needs a battery recharge too, or no mouse events whatsoever will be available to redirect ;-) |
| 00:53.42 | DocScrutinizer05 | the damn battery is worn |
| 01:27.18 | *** join/#maemo robbiethe1st (~robbiethe@104.235.199.86) |
| 01:58.55 | *** join/#maemo LauRoman|Phone (~yaaic@5.14.87.59) |
| 02:17.45 | *** join/#maemo eMHa_ (~mh@p579DBE9C.dip0.t-ipconnect.de) |
| 02:42.39 | *** join/#maemo Defiant (erik@x55b0356c.dyn.telefonica.de) |
| 03:28.44 | *** join/#maemo louisdk (~louisdk@static-5-103-130-65.seas-nve.net) |
| 04:00.22 | *** join/#maemo lobito (~lobito@190.177.197.164) |
| 04:05.01 | *** join/#maemo DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 04:17.04 | *** join/#maemo louisdk (~louisdk@static-5-103-130-65.seas-nve.net) |
| 05:30.49 | *** join/#maemo Vajb (~Vajb@85-76-35-125-nat.elisa-mobile.fi) |
| 06:08.35 | *** join/#maemo vahe (~funtoo@130.193.124.135) |
| 07:40.55 | *** join/#maemo pozitrono (~nu@109.201.143.40) |
| 07:50.54 | *** join/#maemo robink_ (~quassel@unaffilated/robink) |
| 08:07.11 | *** join/#maemo LauRoman (~LauRoman@5-14-87-59.residential.rdsnet.ro) |
| 08:34.51 | *** join/#maemo jonwil (~jonwil@27-33-80-219.tpgi.com.au) |
| 08:36.00 | jonwil | hi |
| 08:50.35 | brolin_empey | jonwil: âlo. |
| 08:51.49 | *** join/#maemo qwazix (~qwazix@Maemo/community/ex-council/qwazix) |
| 09:14.09 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 09:33.31 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 09:36.15 | *** join/#maemo Bono_NL (~Bono@dhcp-077-250-079-027.chello.nl) |
| 09:41.34 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 10:08.08 | *** join/#maemo Bono_NL (~Bono@dhcp-077-250-079-027.chello.nl) |
| 10:19.44 | *** join/#maemo futpib_ (~futpib@37.113.242.93) |
| 10:32.58 | *** join/#maemo realitygaps (~realityga@unaffiliated/realitygaps) |
| 10:37.33 | *** join/#maemo ssvb_ (~ssvb@dsl-espbrasgw1-54f9c5-175.dhcp.inet.fi) |
| 10:40.44 | *** join/#maemo ssvb_ (~ssvb@dsl-espbrasgw1-54f9c5-175.dhcp.inet.fi) |
| 11:05.47 | *** join/#maemo abdullah (~abdullah@95.0.35.150) |
| 11:07.47 | *** join/#maemo realitygaps (~realityga@unaffiliated/realitygaps) |
| 11:23.41 | *** join/#maemo Hurrian (~Hurrian@unaffiliated/rikanee) |
| 11:31.37 | *** join/#maemo Hurrian (~Hurrian@unaffiliated/rikanee) |
| 11:35.27 | *** join/#maemo discopig (~pig@unaffiliated/discopig) |
| 11:40.00 | *** join/#maemo realitygaps (~realityga@unaffiliated/realitygaps) |
| 11:53.20 | freemangordon | Pali: what about something like http://pastebin.com/TF8ywZAq |
| 11:53.42 | freemangordon | the only problem is that events are registered with a delay, but I guess this can be fixed |
| 11:57.42 | Pali | freemangordon: looks good |
| 11:57.51 | Pali | only one problem is in ALS_PATH_RX51_3x |
| 11:58.14 | Pali | path via i2c-adapter is not stable |
| 11:58.25 | freemangordon | yeah, I forgot I touched that one too. But anyway, ^^^ is just POC |
| 11:58.31 | freemangordon | I know |
| 11:58.44 | Pali | there should be more stable symlink in /sys somewhere |
| 11:58.54 | freemangordon | Pali: any clue why events might come delayed? the way mce sets giomonitor? |
| 11:59.17 | Pali | first check that kernel does not delay them |
| 11:59.29 | freemangordon | where? |
| 11:59.42 | Pali | use e.g. program input-events |
| 11:59.44 | freemangordon | evtest spits them immediately |
| 11:59.49 | Pali | ok |
| 12:00.00 | Pali | then it is somewhere in mce.. |
| 12:00.01 | freemangordon | anyway, have to leave now, will look at the issue later |
| 12:00.07 | freemangordon | yes, something in mce |
| 12:00.12 | freemangordon | bb for now |
| 12:00.12 | Wizzup | How much are they delayed? |
| 12:00.29 | freemangordon | hard to say, but more than a second |
| 12:00.56 | freemangordon | also, it is not the same everytime |
| 12:16.49 | *** join/#maemo Vajb (~Vajb@85-76-83-103-nat.elisa-mobile.fi) |
| 12:25.05 | *** join/#maemo pharacker (~partelmi@5.46.176.245) |
| 12:31.30 | *** join/#maemo Oksanaa (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
| 12:32.36 | *** join/#maemo xorly (~xorly@ip-86-49-15-121.net.upcbroadband.cz) |
| 12:35.49 | 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? |
| 12:49.23 | *** join/#maemo louisdk (~louisdk@static-5-103-130-65.seas-nve.net) |
| 13:03.16 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 13:04.50 | DocScrutinizer05 | man apt |
| 13:08.13 | *** join/#maemo raandoom (~raandoom@195.208.103.11) |
| 13:16.12 | *** join/#maemo realitygaps (~realityga@unaffiliated/realitygaps) |
| 13:24.22 | *** join/#maemo raandoom (~raandoom@195.208.103.11) |
| 13:29.45 | *** join/#maemo abdullah (~abdullah@95.0.35.150) |
| 13:31.00 | DocScrutinizer05 | it's of course arguable if those avatar files are really 'config data' |
| 13:31.41 | kerio | they're not |
| 13:31.46 | DocScrutinizer05 | but I think the general take on this is "never delete anything from user's home" |
| 13:32.19 | kerio | the cache should really not be in /home/user though |
| 13:32.32 | kerio | i guess that storing it in MyDocs becomes complicated, however |
| 13:34.20 | *** join/#maemo SmilyOrg (~Smily@93-103-95-89.dynamic.t-2.net) |
| 13:35.06 | DocScrutinizer05 | how so? |
| 13:35.42 | kerio | MyDocs gets unmounted at the user's will |
| 13:35.51 | DocScrutinizer05 | yeah |
| 13:36.01 | kerio | stupid decisions all around, really |
| 13:36.41 | DocScrutinizer05 | well, that's the sort of compromises you need to do when you got only 240MB of / |
| 13:36.48 | *** join/#maemo Djgio07 (~Djgio07@host3-156-dynamic.40-79-r.retail.telecomitalia.it) |
| 13:36.53 | Djgio07 | HI |
| 13:37.21 | DocScrutinizer05 | though ~optification is really a headache |
| 13:38.13 | *** part/#maemo Djgio07 (~Djgio07@host3-156-dynamic.40-79-r.retail.telecomitalia.it) |
| 13:38.19 | DocScrutinizer05 | when the avatar data is no user's config data then it belongs into /opt |
| 13:39.00 | DocScrutinizer05 | at least on a genuine maemo5 system |
| 13:39.30 | DocScrutinizer05 | and yes, it should get cleaned out then |
| 13:39.55 | DocScrutinizer05 | "forgot to clear the cache" sounds like a common mistake |
| 13:41.19 | DocScrutinizer05 | or at your discretion s/cache/tmp/ |
| 13:47.46 | *** join/#maemo SmilybOrg (~Smily@93-103-95-89.dynamic.t-2.net) |
| 13:51.14 | *** join/#maemo FlameReaper-PC (~FR@175.139.21.117) |
| 13:53.13 | *** join/#maemo SmilyOrg (~Smily@93-103-95-89.dynamic.t-2.net) |
| 13:56.27 | *** join/#maemo realitygaps (~realityga@unaffiliated/realitygaps) |
| 13:56.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) |
| 13:57.32 | KotCzarny | or to redefine depending what is running etc |
| 13:57.55 | KotCzarny | with hardcoded settings there is no such flexibility |
| 14:06.00 | *** join/#maemo raandoom (~raandoom@195.208.103.11) |
| 14:08.02 | *** join/#maemo louisdk (~louisdk@static-5-103-130-65.seas-nve.net) |
| 14:14.12 | *** join/#maemo totalizator (~totalizat@degu.pl) |
| 14:14.51 | *** join/#maemo krnlyng (~liar@77.117.2.254.wireless.dyn.drei.com) |
| 14:15.45 | *** join/#maemo raandoom (~raandoom@195.208.103.11) |
| 14:21.21 | *** join/#maemo Ongkut (~pahuyuth@x4d0ae369.dyn.telefonica.de) |
| 14:24.32 | *** join/#maemo Ongkut (~pahuyuth@x4d0ae369.dyn.telefonica.de) |
| 14:40.29 | freemangordon | KotCzarny: why is that? We can always introduce switch<->functionality mapping file |
| 14:40.37 | freemangordon | or gconf or whatever |
| 14:47.29 | Pali | freemangordon: how hard would be to fix dsp driver and include it again into upstream kernel? |
| 14:47.49 | Pali | you already played with that code, so maybe you could know... |
| 14:53.21 | *** join/#maemo trumee (~trumee@c-50-175-121-86.hsd1.tx.comcast.net) |
| 14:54.18 | freemangordon | Pali: they want remoteproc driver. and that wouldn;t be easy |
| 14:54.52 | freemangordon | i'll need remoteproc coff fw loader and who knows what else |
| 14:54.56 | freemangordon | *it'll |
| 15:04.23 | *** join/#maemo trumee (~trumee@c-50-175-121-86.hsd1.tx.comcast.net) |
| 15:09.41 | *** join/#maemo Vajb (~Vajb@85-76-75-118-nat.elisa-mobile.fi) |
| 15:20.31 | *** join/#maemo trumee (~trumee@c-50-175-121-86.hsd1.tx.comcast.net) |
| 15:28.17 | Pali | freemangordon: what is remoteproc? |
| 15:28.43 | freemangordon | Pali: https://www.kernel.org/doc/Documentation/remoteproc.txt |
| 15:31.49 | Pali | ufff |
| 15:32.39 | Pali | now last version of tidspbridge cannot be compiled anymore (on uptream kernel)... |
| 15:33.11 | freemangordon | :( |
| 15:36.12 | *** join/#maemo realitygaps (~realityga@unaffiliated/realitygaps) |
| 15:36.49 | Pali | in old TODO for tidspbridge is nothing about remoteproc |
| 15:37.08 | Pali | there is just: DOFF binary loader: consider pushing to user space |
| 15:37.32 | Pali | only *consider* |
| 16:01.50 | 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 |
| 16:02.35 | Pali | freemangordon: ok |
| 16:05.29 | *** join/#maemo ced117 (~ced117@opensuse/member/ced117) |
| 16:07.32 | freemangordon | Pali: https://github.com/community-ssu/mce/commit/a3f25c56d7f57af5fc5a9c4c375b0db624f70b53 |
| 16:09.38 | Pali | ok |
| 16:10.08 | Pali | now I'm looking at mce/modules/vibrator.c and this code is not compatible with upstrem kernel too... |
| 16:10.29 | Pali | path /sys/class/i2c-adapter/i2c-1/1-0048/twl4030_vibra/pulse does not exist |
| 16:10.42 | freemangordon | vibrator is exported via evdev as well |
| 16:10.49 | Pali | looks like that upstream kernel export twl4030 via input layer too! |
| 16:11.36 | Pali | and twl4030-vibra is registered under audio device |
| 16:12.32 | freemangordon | just a second do boot |
| 16:15.09 | freemangordon | Pali: http://pastebin.com/itKGCpMK |
| 16:15.49 | Pali | EV_FF |
| 16:15.54 | freemangordon | yes |
| 16:15.59 | freemangordon | force-feedback |
| 16:16.22 | Pali | but problem is that event5 name is not stable |
| 16:16.29 | freemangordon | so what? |
| 16:16.29 | Wizzup | use by-id or by-path |
| 16:16.39 | freemangordon | no by-id |
| 16:16.40 | freemangordon | :) |
| 16:16.41 | Wizzup | Or is that not available? |
| 16:16.42 | Wizzup | Yeah, that |
| 16:16.49 | Pali | need to match against "Input device name" (which is "twl4030:vibrator") |
| 16:16.59 | Wizzup | Pali: ls /dev/input/by-id :) |
| 16:17.02 | freemangordon | Pali: we can add another class |
| 16:17.15 | Pali | or maybe just "*:vibrator" |
| 16:17.16 | freemangordon | the same way I did for switches |
| 16:17.30 | freemangordon | Pali: no, we'd rather mach on EV_FF |
| 16:17.33 | freemangordon | *match |
| 16:17.37 | freemangordon | instead of a name |
| 16:17.49 | freemangordon | I was thinking the same for gpio-keys |
| 16:17.53 | Pali | Wizzup: no by-id in Maemo :-( |
| 16:18.19 | Pali | freemangordon: yes, match against EV_FF could work too |
| 16:18.24 | freemangordon | to parse supported keys/switches and to choose what we need |
| 16:18.46 | Pali | $ ll /sys/class/input/input*/capabilities/ff |
| 16:18.57 | Pali | freemangordon: that match is really easy ^^^ |
| 16:19.00 | freemangordon | hmm, no there is evdev ioctl for that |
| 16:19.16 | Pali | ok |
| 16:19.24 | freemangordon | as we can get the supported buttons as well |
| 16:22.15 | Wizzup | getting the name is EVIOCGNAME |
| 16:23.58 | 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? |
| 16:24.15 | Wizzup | yes |
| 16:24.19 | freemangordon | great |
| 16:24.39 | Wizzup | C, right? |
| 16:24.43 | freemangordon | yep |
| 16:24.50 | Wizzup | will do |
| 16:24.56 | freemangordon | thanks! |
| 16:25.11 | Wizzup | do you want to match against something hardcoded? |
| 16:25.19 | Wizzup | (I guess so?) |
| 16:25.23 | freemangordon | Wizzup: BTW, can we disable some of the keys via evdev interface? |
| 16:25.31 | freemangordon | no hadcoded |
| 16:25.36 | freemangordon | a parameters |
| 16:26.01 | freemangordon | like match("/dev/input/event1", EV_KEY |
| 16:26.01 | 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 |
| 16:26.11 | freemangordon | oops |
| 16:26.17 | freemangordon | ... |
| 16:26.22 | Wizzup | match(file, EV_KEY, KEY_A) ? |
| 16:26.33 | freemangordon | yes |
| 16:26.38 | Wizzup | sure |
| 16:26.49 | freemangordon | but 2 and 3 parameters should be arrays IMO |
| 16:27.14 | freemangordon | or somesuch |
| 16:27.28 | Wizzup | ack |
| 16:27.30 | freemangordon | to be able to match both EV_SW and EV_KEY, for example |
| 16:27.46 | freemangordon | with apprpriate masks for keys and switches |
| 16:27.48 | Wizzup | I would say that param 2 should not be - since EV_SW cannot have KEY_A for example |
| 16:27.53 | Wizzup | well, I guess that is possible though |
| 16:27.57 | Wizzup | just needs to be well defined/clear :) |
| 16:28.22 | freemangordon | haveing integer array as a second and third parameter should do the job |
| 16:28.33 | Wizzup | ack. |
| 16:28.33 | freemangordon | {EV_KEY, EV_SW, -1} |
| 16:28.49 | freemangordon | and array of integer arrays for the third |
| 16:29.56 | freemangordon | {{KEY_A, KEY_B, -1},{SW_KEYPAD_SLIDE, SW_CAMERA_LENS_COVER, -1}}; |
| 16:30.03 | freemangordon | Wizzup: ^^^ |
| 16:32.58 | Wizzup | Ack |
| 16:35.54 | *** join/#maemo trumee (~trumee@c-50-175-121-86.hsd1.tx.comcast.net) |
| 16:37.36 | Wizzup | will need like 30 mins. |
| 16:38.06 | freemangordon | no hurry |
| 16:54.52 | *** join/#maemo trumee (~trumee@c-50-175-121-86.hsd1.tx.comcast.net) |
| 16:55.45 | Pali | freemangordon, Wizzup: there is sysfs entry for disabling: /sys/class/input/input*/device/disabled_keys /sys/class/input/input*/device/disabled_switches |
| 16:55.55 | freemangordon | Pali: I know |
| 16:56.22 | freemangordon | the point is that it would have been easier if we could do it via evdev interface |
| 16:56.55 | Pali | but this is specific for gpio-keys.ko driver :-( |
| 16:57.04 | Wizzup | Pali: ah, tmyk |
| 16:57.10 | Wizzup | ah, right. |
| 16:57.20 | freemangordon | Pali: yes, exactly |
| 16:58.26 | Pali | gpio-keys.ko support it only via sysfs |
| 16:59.18 | Pali | https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/input/keyboard/gpio_keys.c#n58 |
| 17:02.22 | freemangordon | yeah |
| 17:12.55 | *** join/#maemo ced117 (~ced117@opensuse/member/ced117) |
| 17:15.22 | *** join/#maemo trumee (~trumee@c-50-175-121-86.hsd1.tx.comcast.net) |
| 17:22.57 | *** join/#maemo realitygaps (~realityga@unaffiliated/realitygaps) |
| 17:26.03 | Wizzup | freemangordon: http://sprunge.us/BJdY?c something like this |
| 17:26.24 | Wizzup | the defines at the top of the function are taken from evtest |
| 17:30.16 | Wizzup | ah - there is a bit more I have to clean up |
| 17:30.19 | Wizzup | stray call that is not required |
| 17:33.59 | Wizzup | http://sprunge.us/baKa?c should do it |
| 17:41.26 | *** join/#maemo at1as (~at1as@kurios.r4780y.com) |
| 17:45.47 | Wizzup | removed extra q = 0; -> http://sprunge.us/ZVfM?c |
| 18:00.17 | Wizzup | the NULL is not required in the key_keys arg |
| 18:08.56 | *** join/#maemo louisdk (~louisdk@static-5-103-130-65.seas-nve.net) |
| 18:18.08 | *** join/#maemo sparetire_ (~sparetire@unaffiliated/sparetire) |
| 18:25.03 | *** join/#maemo rosseaux (~BeRo@2a00:1828:2000:859::2) |
| 18:37.09 | DocScrutinizer05 | chem|st: xes: warfare: why does tmo block *reading* visitors? |
| 18:37.30 | DocScrutinizer05 | >>Sorry, it seems that you are using an IP address or a proxy that is listed in the forum anti spam blacklist.<< |
| 18:37.53 | DocScrutinizer05 | how would a visitor spam the forum? |
| 18:40.01 | 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 |
| 18:45.42 | *** join/#maemo Vajb (~Vajb@85-76-146-162-nat.elisa-mobile.fi) |
| 19:03.02 | *** join/#maemo Smily (~Smily@93-103-95-89.dynamic.t-2.net) |
| 19:04.22 | *** join/#maemo trumee (~trumee@c-50-175-121-86.hsd1.tx.comcast.net) |
| 19:08.05 | *** join/#maemo Roth (~quassel@2601:18c:c700:c4d3:563:d4c1:2c05:b63f) |
| 19:08.17 | *** join/#maemo raandoom (~raandoom@195.208.103.11) |
| 19:08.34 | *** join/#maemo Smily (~Smily@93-103-95-89.dynamic.t-2.net) |
| 19:14.55 | freemangordon | Wizzup: thanks; will look at later |
| 19:15.07 | Wizzup | no rush |
| 19:23.09 | 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? |
| 19:31.50 | DocScrutinizer05 | "sorry, Tor users are not allowed to *read* this forum" is silly |
| 19:36.48 | 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 |
| 19:37.55 | DocScrutinizer05 | no read access should get blocked, only write access |
| 19:38.27 | DocScrutinizer05 | (except in case of [D]DoS) |
| 19:40.04 | *** join/#maemo pozitron (~nu@109.201.143.40) |
| 19:43.16 | 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 |
| 19:51.07 | bencoh | +1 for read-access |
| 19:55.37 | *** join/#maemo louisdk (~louisdk@static-5-103-130-65.seas-nve.net) |
| 19:57.43 | *** join/#maemo realitygaps (~realityga@unaffiliated/realitygaps) |
| 20:03.50 | *** join/#maemo NIN101 (~core@mail2.quitesimple.org) |
| 20:06.01 | *** join/#maemo arossdotme (~zxy@host-92-11-93-192.as43234.net) |
| 20:06.30 | Pali | freemangordon: new version of module-init-tools is in cssu-devel, now modprobe should take params also from kernel cmdline |
| 20:11.51 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 20:15.31 | *** join/#maemo Venusaur (~wdwrwf@wikipedia/Antonio-Lopez) |
| 20:32.55 | *** join/#maemo peetah (~peetah@cha92-9-82-236-202-86.fbx.proxad.net) |
| 20:34.24 | 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' |
| 20:36.40 | DocScrutinizer05 | tmo engine should only blacklist actual offenders, not do a preemptive block of whole RMBs |
| 20:38.23 | 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?) |
| 20:43.23 | *** join/#maemo LauRoman (~LauRoman@5-14-87-59.residential.rdsnet.ro) |
| 20:58.42 | freemangordon | Pali: good |
| 20:58.46 | 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. |
| 20:59.30 | freemangordon | Pali: coiuld you upgrade to -rc7, to see if net bug is still there? If it is, I'll try to bisect |
| 20:59.33 | *** join/#maemo krnlyng (~liar@178.112.236.113.wireless.dyn.drei.com) |
| 20:59.44 | DocScrutinizer05 | warfare: I see |
| 21:00.42 | DocScrutinizer05 | warfare: a tad cumbersome for innocent users only wanting to read a post and getting rejected just because they have the wrong IP |
| 21:01.18 | warfare | DocScrutinizer05: yes, definitely. Maybe there is some anti-spam support in vbulletin. |
| 21:01.25 | DocScrutinizer05 | maybe we need a read-only mirror without filtering ;-) |
| 21:37.22 | *** join/#maemo ced117 (~ced117@opensuse/member/ced117) |
| 22:08.12 | xes | DocScrutinizer05: warfare: hi! Vbullettin has antispam modules that fail very very often |
| 22:21.03 | xes | if one ip is in our blacklist it means that it's been reported for malicious activity. I have checked almost every complaint and there was a real plausible reason for the presence in the list. So, in that list there aren't "innocent" users. Which is the purpose to grant a read only access to these bots and spammers? |
| 22:25.20 | xes | since the blacklist has been applied, i can remember <10 spam posts. When there was only the vbullettin antispam .... well, ask the numbers to the moderators |
| 22:36.39 | DocScrutinizer05 | xes: what about Tor nodes? |
| 22:36.53 | DocScrutinizer05 | and huge NATted networks |
| 22:39.46 | xes | DocScrutinizer05: do you know which kind of traffic is generated by tor? |
| 22:40.04 | DocScrutinizer05 | all sorts of traffic are routed via tor |
| 22:40.39 | DocScrutinizer05 | yes, probably a lot of spammers use tor as well. But also absolutely innocent users do |
| 22:41.30 | xes | sure. One you have a minute compare the tor exit nodes list with the list of recent attacks on the web |
| 22:41.42 | DocScrutinizer05 | I don't know traffic _generated_ by tor though. Except of course between tor nodes |
| 22:42.33 | xes | anyway, i can see how this solution is far from perfection (if a perfection exists) |
| 22:42.42 | DocScrutinizer05 | Tor is basically a NAT service, at least as seen from the outside |
| 22:44.02 | xes | but we need an efficient solution that vbulletin addons can't provide |
| 22:44.07 | DocScrutinizer05 | there are other NAT that have a very huge userbase behind them. GPRS cellular serices come to mind, and in some eastern-european countries it seems even wired internet is fed through a NAT |
| 22:46.13 | DocScrutinizer05 | I can see a very simple 10-liner "addon" to handle this: on register page check IP of current user against RBL IP list. If match, send that IP to FW for blocking |
| 22:46.19 | xes | yes, i know |
| 22:46.42 | kerio | "eastern-european" |
| 22:46.56 | kerio | one of the major italian ISPs does carrier-grade NAT |
| 22:47.06 | DocScrutinizer05 | hmm dunno, kerio. That's what I seem to remember |
| 22:47.17 | kerio | no i mean |
| 22:47.20 | kerio | you don't have to go that far |
| 22:47.24 | DocScrutinizer05 | ok |
| 22:47.28 | kerio | G8 country |
| 22:47.37 | kerio | carrier-grade NAT on a major wired ISP |
| 22:47.46 | warfare | kerio: most major german cable providers do this. |
| 22:48.09 | kerio | i think that verizon in the US does nat64 on the phones |
| 22:52.57 | DocScrutinizer05 | how about giving my 10-liner idea a shot? |
| 22:56.31 | *** join/#maemo louisdk (~louisdk@static-5-103-130-65.seas-nve.net) |
| 23:04.39 | DocScrutinizer05 | tmo could even report each IP accessing the login page, and FW does the lookup in the RBL and adds the IP to netfilter only when it's a hit in RBL |
| 23:39.50 | *** join/#maemo LauRoman|Phone (~yaaic@5-14-87-59.residential.rdsnet.ro) |
| 23:47.16 | *** join/#maemo pozitron (~nu@e9.85.7a9f.ip4.static.sl-reverse.com) |
| 23:51.19 | *** join/#maemo realitygaps (~realityga@unaffiliated/realitygaps) |
| 23:54.42 | *** join/#maemo louisdk (~louisdk@static-5-103-130-65.seas-nve.net) |