**** BEGIN LOGGING AT Wed Jan 13 02:59:59 2016 Jan 13 04:34:35 DocScrutinizer05: yes, but does mce also listen for the touch events from Xorg? Jan 13 04:35:55 I was asking what program actually connect to the X server, asks it to send it all touchscreen events, then somehow cause vibration. Jan 13 04:36:10 I don't think that's mce. Jan 13 04:39:08 kill -sigstop `pidof mce` Jan 13 04:39:29 -->no more vibra feedback from touchscreen Jan 13 04:39:40 kill -sigcont `pidof mce` Jan 13 04:40:02 --> all cued vibra events come out Jan 13 04:40:22 queued even Jan 13 04:40:56 so the answer is: yes it's mce that finally causes the touchscreen vibra Jan 13 04:40:57 Of course, because they go through mce. Jan 13 04:41:09 I'm not asking that. Jan 13 04:41:25 If you stop/continue Xorg you'll probably get the same thing.e Jan 13 04:41:33 So Xorg == mce? Jan 13 04:41:59 you're interested in more answers? Jan 13 04:42:30 I guess not, like you always been Jan 13 04:42:59 * DocScrutinizer05 fixes his ignore list. wonders what happened to it Jan 13 04:47:09 mce doesn't initiate the chain of events. Neither does twl*vibra Jan 13 04:47:09 They're both parts of the chain I'm probably not asking about. Jan 13 04:47:09 Iiirc, the events go through Xorg, and I'm asking where they go from there. I don't think it's directly to mce. I think another program sends messages to mce. Jan 13 04:47:12 also, input lag, messages will probably appear all at once. Jan 13 05:04:43 lsof |egrep "mce|Xorg" |grep unix|sort -k6 Jan 13 05:06:09 I think mce does that for screen locking. Jan 13 05:06:14 nm Jan 13 05:07:27 I'll look into it in an hour or so. Jan 13 05:22:15 https://github.com/community-ssu/mce/blob/master/event-input.h#L37 Jan 13 05:32:32 https://github.com/community-ssu/mce/blob/master/event-input.c#L644 Jan 13 05:47:32 * Maxdamantus wonders if "PatternTouchscreen" in mce.ini is used. Jan 13 05:47:34 looks like it's not. Jan 13 05:48:47 Okay, got it. Jan 13 05:48:51 It's maemo-xinput-sounds Jan 13 05:49:18 Just did a grep for PatternTouchscreen across a backup of the root filesystem. Jan 13 05:49:59 * Maxdamantus wonders why they didn't just put it in mce. Jan 13 05:51:31 DocScrutinizer05: am I still ignored btw? Jan 13 05:55:44 * Maxdamantus suspects that's a yes and doc will be searching through mce for eternity looking for the bit where it triggers a vibration in response to the touchscreen. Jan 13 06:01:45 ~touchscreen vibration Jan 13 06:01:45 methinks touchscreen vibration is maemo-xinput-sounds Jan 13 07:54:36 DocScrutinizer05: jonwil: any clue who and how uses "sleep_ind" gpio? Jan 13 07:55:09 err, gpio? hmm Jan 13 07:55:21 wait, is this in our out? Jan 13 07:55:23 yep, 162 Jan 13 07:55:32 mompls Jan 13 07:57:43 sleep_ind is an output from SoC to enable blinking kbd backlight Jan 13 07:58:11 I know, my question is who uses it Jan 13 07:58:21 related to a /sys/*/??? I always forget the name of Jan 13 07:58:42 however, it is referenced in an .qwk script in getbootstate Jan 13 07:58:54 in a what? Jan 13 07:59:37 it's used in preinit(?) via `echo 0 >/sys/bla/foo/bar` Jan 13 08:01:01 /sbin/read_cfg.awk Jan 13 08:01:42 echo active > /sys/devices/platform/gpio-switch/sleep_ind/state Jan 13 08:01:51 (sbin/preinit) Jan 13 08:02:27 line 331 Jan 13 08:02:53 hmm Jan 13 08:02:58 then a nifty >> awk '/sleep_ind/{ if ($2 == 1) { VALUE="active"; } else { VALUE="inactive"; } print VALUE > "/sys/devices/platform/gpio-switch/sleep_ind/state" }' < /etc/pmconfig << Jan 13 08:03:58 yeah Jan 13 08:04:12 getbootstate does similar stuff Jan 13 08:04:15 got it Jan 13 08:04:20 :-) Jan 13 08:07:53 * DocScrutinizer05 frowns at using awk in #1 preinit Jan 13 08:08:34 I know it's per default just another shade of messybox, but hey.. Jan 13 08:09:09 feels sort of wrong Jan 13 08:19:24 pretty funny read: /sbin/fiasco-do-update Jan 13 08:24:05 and /usr/sbin/cmt-factory-reset Jan 13 08:44:56 Maxdamantus, DocScrutinizer05: looks like I was referring to "tactile", which is only in extras Jan 13 08:46:06 hm? Jan 13 08:46:18 touchscreen feedback / vibration Jan 13 08:47:00 ohh [2016-01-12 Tue 11:14:12] Maxdamantus: regarding touchscreen vibrating feedback, there is a daemon in a separate package Jan 13 08:47:13 yeah Jan 13 08:47:42 but I'm not sure it's what you're looking for since it's in extras-devel Jan 13 08:48:01 I'm not really looking for anything :-) Jan 13 08:48:21 you or Maxdamantus :) Jan 13 08:48:54 no idea, never heard of tactile Jan 13 08:49:19 touchscreen vibra feedback is maemo core Jan 13 08:49:45 maybe tactile is made to tweak that stuff Jan 13 08:51:15 there been an idea a few years(=) ago to not only give vibra feedback for pen-down but also when pen hits borders of widgets like buttons or icons or whatever Jan 13 08:52:01 a tad useless since you usually don't try to hit buttons with pen-down Jan 13 08:52:11 s/with/while/ Jan 13 08:52:12 DocScrutinizer05 meant: a tad useless since you usually don't try to hit buttons while pen-down Jan 13 08:53:45 hmm >> tactile provides improved tactile feedback with different patterns to improve the user experience on the N900.<< Jan 13 08:54:04 xes: aren't bfs/bfq useful in case of high cpu load? Jan 13 08:54:25 brainfuck scheduler? Jan 13 08:54:31 yeah Jan 13 11:02:02 bencoh: yes high cpu load, high I/O and slow storage devices producing high I/O wait Jan 13 11:03:20 ah, cool Jan 13 12:04:03 Sounds like it would be useful on a N900 then Jan 13 12:04:12 which has slow I/O speeds Jan 13 12:04:15 and slow storage devices Jan 13 12:04:21 and in some cases high CPU load Jan 13 12:56:22 i'm using a kernel with BFS/BFQ patches into a (slooow) Sony VGN-P11Z and it gives a nice kick to overall system usability Jan 13 12:56:29 http://cs.unm.edu/~eschulte/classes/cs587/data/bfs-v-cfs_groves-knockel-schulte.pdf Jan 13 12:57:37 ^^ "Conclusion: The results indicate that CFS outperformed BFS with minimizing turnaround time but that BFS outperformed CFS for minimizing latency. This indicates that BFS is better for interactive tasks that block on I/O or user input and that CFS is better for batch processing that is CPU bound." Jan 13 13:04:38 now to find cfs patches for 2.6.28 Jan 13 13:05:07 kolivas's website only has 3.x and 4.x Jan 13 13:13:44 bencoh: those patches are included also into kernel-pwck https://garage.maemo.org/frs/download.php/9948/kernel-pwck-2.6.28.10pwck2.tar.gz Jan 13 13:14:00 ah, nice Jan 13 13:22:07 old CK's patches: http://korg.cs.utah.edu/pub/linux/kernel/people/ck/patches/2.6/ Jan 13 13:22:28 and BFQ: http://algo.ing.unimo.it/people/paolo/disk_sched/patches/ Jan 13 13:25:36 maybe that with a kernel 2.6.28 these patches were in a early development stage.. Jan 13 13:40:58 maybe Jan 13 13:57:22 is there a git repo for kernel-power? Jan 13 14:04:40 *** Can't find default configuration "arch/arm/configs/rx51_defconfig"! Jan 13 14:04:59 when building kernel-power (kp53) from source package (apt-get source) in sb... interesting. Jan 13 14:05:26 https://vcs.maemo.org/git/?p=kernel-power Jan 13 14:06:00 ah, tx Jan 13 14:07:34 while kernel-cssu is https://github.com/community-ssu/kernel-cssu/ Jan 13 14:07:59 Is there an equivalent of xdg-open in Fremantle? Jan 13 17:55:46 DocScrutinizer05: did that amixer thing for my 'silent earpiece' problem. basically no difference with yours :( Jan 13 17:57:44 http://paste.debian.net/365587/ Jan 13 18:05:42 freemangordon: pulseaudio log for same situation .. don't know if it's giving something useful: http://paste.debian.net/365589/ Jan 13 18:07:46 i added --log-level info in the startup script for pulseaudio Jan 13 18:13:16 DocScrutinizer05: restarted pulseaudio (after which earpiece works). did amixer -c0 exactly as you did it. no difference in output between the working and non-working states Jan 13 18:18:05 freemangordon: in 'working' state: http://paste.debian.net/365590/ Jan 13 18:18:58 Jan 13 19:50:20 fremantle pulseaudio[5719]: voice-hw-sink-input.c: 149: 3 frames found from queue (dl buf size 640) Jan 13 18:19:01 Jan 13 19:50:20 fremantle pulseaudio[5719]: voice-cmtspeech.c: cmtspeech_dl_buffer_release(0xa2c70) failed return value -32 Jan 13 18:19:13 this is what i have in non-working state :/ Jan 13 18:27:49 bencoh: KotCzarny : and other interested parties: http://pavelmachek.livejournal.com/130784.html Jan 13 18:30:39 that's in connection with voice calls on upstream kernel :) Jan 13 18:33:56 yeah, we saw that already :) Jan 13 18:34:06 ah, ok :) Jan 13 18:34:18 that's still cool tough Jan 13 18:34:22 though* Jan 13 18:34:48 i'm happy. guess now my 2nd N900 will finally have good use ;) Jan 13 18:35:11 doesn't help me with my silent earpiece thing though. Jan 13 18:37:03 Sicelo: vanilla kernel? Jan 13 18:39:06 article says mainline/4.4-rc8, so.... apparently Jan 13 19:17:33 freemangordon: this is everything relating to pulseaudio in my syslog for 2 days: http://paste.debian.net/365607/ Jan 13 19:17:56 the shutdown on the 12th must have been due to empty battery. Jan 13 19:19:39 anyway, looks too me i either have fsckd up pulseaudio (which a reinstall didn't fix?) or something's up with some of the modules (voice-cmtspeech and maybe others?) Jan 13 19:56:09 hello Jan 13 19:57:37 does anybody knows what is the /home/user/.ash_history file ? Jan 13 19:58:24 only bash has history or even ash? Jan 13 20:03:08 just `cat` yours for the answer :) Jan 13 20:14:22 it has few lines of commands but from 2011 Jan 13 20:15:15 have you moved to bash since then? ;) Jan 13 20:17:06 no Jan 13 20:19:17 maybe some script created that file time ago :) Jan 13 20:23:35 you don't use terminal? Jan 13 20:24:53 yes Jan 13 20:25:18 if you type set in xterm Jan 13 20:25:29 you can see HISTFILE='/home/user/.ash_history' Jan 13 20:29:52 i rm the file, now has been created again without old commands but with latest commands Jan 13 21:13:05 Sicelo: updated maemo fb page with 8days no response msg... **** ENDING LOGGING AT Thu Jan 14 02:59:58 2016