| *** lizardo has quit IRC | 00:01 | |
| *** Guest44583 has quit IRC | 00:07 | |
| luf | ~seen pali | 00:32 |
|---|---|---|
| infobot | pali <~pali@unaffiliated/pali> was last seen on IRC in channel #maemo, 1d 5h 54m 6s ago, saying: 'and usb cable (in pc suite/usb mass storage)?'. | 00:32 |
| luf | freemangordon: I have a fix for the bluez BT name ;) I'm not sure it's the final but you know ... | 00:43 |
| *** myuu__ has joined #maemo-ssu | 00:43 | |
| *** _ade_ has quit IRC | 01:05 | |
| luf | freemangordon: the fix works as expected. Only set it during boot. Not on repeatable BT on/off actions. | 01:15 |
| *** luf1 has joined #maemo-ssu | 01:18 | |
| *** _rd has quit IRC | 01:34 | |
| *** ekze has quit IRC | 01:51 | |
| freemangordon | luf: ok, will ask you for details tomorrow :) | 01:55 |
| merlin1991 | luf: but what if someone changes the device name in the menu? | 01:59 |
| luf | merlin1991: It should still work. The fix only set "some" name during boot. It doesn't load the name or do something more. | 02:09 |
| luf | I'm going to the bed now. Good night. | 02:10 |
| *** luf has quit IRC | 02:11 | |
| *** luf1 has quit IRC | 02:15 | |
| *** M4rtinK has joined #maemo-ssu | 02:24 | |
| *** M4rtinK has quit IRC | 02:35 | |
| *** arcean has quit IRC | 03:03 | |
| *** nox- has quit IRC | 03:30 | |
| *** ekze has joined #maemo-ssu | 04:24 | |
| *** amiconn_ has joined #maemo-ssu | 05:27 | |
| *** amiconn has quit IRC | 05:27 | |
| *** amiconn_ is now known as amiconn | 05:27 | |
| *** DocScrutinizer05 has quit IRC | 06:44 | |
| *** DocScrutinizer05 has joined #maemo-ssu | 06:44 | |
| *** freemangordon has quit IRC | 08:07 | |
| kerio | goddammit i needed fmg :( | 08:18 |
| *** M13 has joined #maemo-ssu | 08:54 | |
| *** freemangordon has joined #maemo-ssu | 09:02 | |
| *** _rd has joined #maemo-ssu | 09:17 | |
| *** luf has joined #maemo-ssu | 09:22 | |
| *** povbot has joined #maemo-ssu | 09:33 | |
| *** ChanServ sets mode: +v povbot | 09:33 | |
| *** ekze has quit IRC | 10:10 | |
| *** ekze has joined #maemo-ssu | 10:18 | |
| *** X-Fade has quit IRC | 10:24 | |
| *** X-Fade has joined #maemo-ssu | 10:24 | |
| *** _rd has quit IRC | 11:32 | |
| *** arcean has joined #maemo-ssu | 11:39 | |
| *** dhbiker has quit IRC | 11:40 | |
| *** M4rtinK has joined #maemo-ssu | 11:51 | |
| *** wmarone_ has joined #maemo-ssu | 12:05 | |
| *** wmarone__ has quit IRC | 12:05 | |
| *** toxaris has joined #maemo-ssu | 12:08 | |
| *** arcean_ has joined #maemo-ssu | 12:27 | |
| *** arcean has quit IRC | 12:30 | |
| *** Flyser has quit IRC | 13:10 | |
| *** dhbiker has joined #maemo-ssu | 13:21 | |
| *** lizardo has joined #maemo-ssu | 13:24 | |
| *** arcean_ is now known as arcean | 13:56 | |
| luf | freemangordon: ping | 14:40 |
| *** toxaris has quit IRC | 14:48 | |
| *** fredrinLap has quit IRC | 15:06 | |
| *** fredrinLap has joined #maemo-ssu | 15:10 | |
| freemangordon | luf: pong | 15:20 |
| luf | freemangordon: I'm uploading new version and the patch to the merlin1991. | 15:29 |
| luf | I want also something else but I forget it :( | 15:30 |
| freemangordon | luf: may I see the patch? | 15:30 |
| luf | Sure. | 15:31 |
| freemangordon | luf: write those down, and hope you'l not forget that you wrote it. And where :P | 15:31 |
| luf | :D Sure. | 15:31 |
| freemangordon | it the patch somewhere in github/gitorious? | 15:32 |
| freemangordon | pastebin? | 15:32 |
| luf | Nope. MMNT | 15:32 |
| freemangordon | ok :) | 15:32 |
| luf | http://merlin1991.at/~luf/bluez/source/221_name_init.patch | 15:35 |
| luf | I don't like it very much but it works. | 15:36 |
| freemangordon | hehe | 15:36 |
| luf | I'll upload also logs so you can take a look what happens in N900 ;) | 15:36 |
| freemangordon | why didn't you implement that on ON? | 15:36 |
| freemangordon | but on OFF | 15:36 |
| luf | You'll see in logs. | 15:36 |
| freemangordon | aah, ok | 15:37 |
| luf | MMNT @work | 15:37 |
| luf | I received some request so I have to focus on that right now. | 15:37 |
| freemangordon | ok, no hurry | 15:38 |
| luf | The reason is that the answer from kernel comes after the BT dev is changed to state DOWN (if down is default). | 15:38 |
| freemangordon | hmm, and what 4.60 does? | 15:38 |
| luf | When the BT device is by default on it stays on and the answer from kernel is processed well. | 15:39 |
| luf | Nothing like that :) | 15:39 |
| freemangordon | :) | 15:39 |
| luf | Huge rework in name ... as it's splitted to adapter name and device name in 4.99. | 15:39 |
| freemangordon | I see | 15:39 |
| freemangordon | well, I agree the patch looks ugly, but as long as it works (and merlin1991 approves it) it should be ok | 15:40 |
| freemangordon | i'll try to fix packaging later | 15:40 |
| luf | I don't understand why the kernel answer is postponed :( | 15:42 |
| freemangordon | hmm, could it be that the queue is not processed? | 15:42 |
| freemangordon | i.e. noone reads the socket when there is a message | 15:44 |
| luf | freemangordon: possible. But I don't see it in the source code. | 15:45 |
| luf | logs uploaded. | 15:46 |
| luf | merlin1991.at/~luf/bluez/logs | 15:46 |
| luf | freemangordon: the patch is like hammer. It fix only the situation when no name initialized when booting with by default disabled BT device. | 15:47 |
| freemangordon | yeah, I see | 15:48 |
| luf | I want to be as few invasive as possible. It would be better to find the root cause but I'm affraid it's in kernel maybe. | 15:48 |
| luf | syslog.bluez_4.99.devoff - booting with BT disabled by default | 15:49 |
| luf | syslog.bluez_4.99.devon - booting with BT enabled by default | 15:50 |
| freemangordon | luf: but why there is this: | 15:50 |
| luf | syslog.bluez_4.99.fixed_btname_v1 - booting with BT disabled by default with the patch | 15:50 |
| kerio | freemangordon: btw busybox-power was updated | 15:50 |
| kerio | no versioning issue for that | 15:50 |
| freemangordon | the fuck, paste don't work :( | 15:50 |
| luf | freemangordon: :) | 15:51 |
| freemangordon | ok, i'll write it | 15:51 |
| luf | feel free to write filename and line number ;) | 15:51 |
| freemangordon | 'Setting name Luf - Nokia N900' | 15:51 |
| freemangordon | in devoff file | 15:51 |
| luf | It's trying to set the name and send it into kernel. But the answer returned after HCI dev down. | 15:52 |
| freemangordon | aaah, I see | 15:52 |
| freemangordon | luf: i'll have a look into the code | 15:53 |
| luf | I traced it down to hci_send_command (plugins/hciops.c:hciops_set_name() OCF_CHANGE_LOCAL_NAME: sent Luf - Nokia N900) | 15:53 |
| freemangordon | yes | 15:53 |
| freemangordon | I saw that | 15:53 |
| luf | answer is: plugins/hciops.c:cmd_complete() OCF_CHANGE_LOCAL_NAME: index 0 status 0 | 15:53 |
| freemangordon | ok | 15:53 |
| luf | below: HCI dev 0 down | 15:53 |
| luf | That's the problem. | 15:53 |
| freemangordon | ok, got it | 15:54 |
| luf | There is no "HCI dev 0 down" when BT device is enabled by default so the name is set as expected. | 15:54 |
| luf | No idea why plugins/hciops.c:io_security_event is postponed (it's some callback). | 15:55 |
| *** NIN101 has joined #maemo-ssu | 16:06 | |
| *** M13 has quit IRC | 16:11 | |
| luf | The reading from kernel/AF_BLUETOOTH socket is done using g_io_add_watch_full(chan, G_PRIORITY_LOW, cond, io_security_event, GINT_TO_POINTER(index), NULL); | 16:13 |
| freemangordon | luf: it seems kernel is missing a call to hci_req_complete | 16:18 |
| freemangordon | for HCI_OP_WRITE_LOCAL_NAME | 16:19 |
| freemangordon | nwer kernels have it | 16:19 |
| freemangordon | *newer | 16:19 |
| freemangordon | hmm, actually kernel is missing LOTS OF code, I wonder how this works at all :D | 16:21 |
| freemangordon | luf: I think I have a better idea | 16:29 |
| luf | Shit. I don't want to patch kernel ... but maybe I should :( | 16:29 |
| freemangordon | instead of using "the hammem" | 16:29 |
| freemangordon | no,no | 16:29 |
| luf | freemangordon: I'm listening. | 16:29 |
| freemangordon | we won't touch the kernel | 16:29 |
| freemangordon | so,... | 16:29 |
| luf | Why not? | 16:29 |
| luf | :) | 16:29 |
| freemangordon | hehe | 16:30 |
| freemangordon | so,... | 16:30 |
| luf | It should go into KP52 or KP53 ... | 16:30 |
| freemangordon | call OCF_READ_LOCAL_NAME | 16:30 |
| freemangordon | after the call OCF_CHANGE_LOCAL_NAME | 16:30 |
| freemangordon | that way we will mimic the expected behaviour | 16:31 |
| luf | I don't understand what do you mean with call OCF_READ_LOCAL_NAME? | 16:31 |
| freemangordon | fuuck, why copy/paste don't work | 16:31 |
| freemangordon | stupid remmina :( | 16:31 |
| luf | Aaah hci_send_cmd ... I get it. | 16:31 |
| freemangordon | yes | 16:31 |
| luf | so OCF_READ_LOCAL_NAME + OCF_CHANGE_LOCAL_NAME + inquiry ? | 16:32 |
| freemangordon | the opposite | 16:32 |
| freemangordon | first change and the read | 16:32 |
| luf | Ahhh sorry my mistake. | 16:32 |
| freemangordon | or change + inquiry (i don't know what inquiry does) | 16:33 |
| luf | Ok. I'll try it. | 16:33 |
| freemangordon | luf, I don't know what completion comes on device off | 16:33 |
| freemangordon | but it is not for name change AIUI | 16:33 |
| luf | where did you find missing hci_req_complete ? | 16:34 |
| freemangordon | my point was 1. change 2. read 3. immediately use the name from the kernel | 16:34 |
| *** dafox has joined #maemo-ssu | 16:34 | |
| freemangordon | that way if kernel change operation has failed for some reason , your read will return blank | 16:35 |
| freemangordon | (and it will be the same as change complete never comes) | 16:35 |
| freemangordon | luf: in internet, newer kernels | 16:35 |
| freemangordon | look for hci_cc_write_local_name | 16:36 |
| freemangordon | google for ^^^ | 16:36 |
| freemangordon | luf: AIUI the complition is first found in 3.0 | 16:38 |
| freemangordon | mgmt_set_local_name_complete ;) | 16:38 |
| freemangordon | kernel function | 16:38 |
| luf | Hmm it seems to me that reading form the socket is in main loop. And during the initialization there is no possibility to get into main loop. | 16:43 |
| freemangordon | you mean the you cannot get the result from "read"? | 16:44 |
| luf | I think so. | 16:45 |
| luf | But I should be wrong. | 16:45 |
| freemangordon | luf: damn, code does exactly this :D | 16:48 |
| freemangordon | look in hciops.c | 16:49 |
| freemangordon | cmd_complete() | 16:49 |
| luf | Yes I know. | 16:49 |
| luf | But it waits for the kernel response which come so late. | 16:49 |
| luf | I think you want to send it ASAP :) | 16:50 |
| freemangordon | luf: it wait for response that never comes | 16:50 |
| freemangordon | *waits | 16:50 |
| freemangordon | AIUI | 16:50 |
| freemangordon | no matter on/off trickery | 16:50 |
| luf | It comes after the dev is down. | 16:51 |
| freemangordon | look at mgmt_handle_event | 16:51 |
| luf | what file? | 16:51 |
| freemangordon | main.c | 16:51 |
| freemangordon | though I might be wrong | 16:52 |
| luf | Why this file? | 16:53 |
| freemangordon | well, i'll check the logs once again, maybe I miss something | 16:54 |
| luf | It read the result using: io_security_event from plugins/hicops.c | 16:54 |
| luf | And it's assigned as callback for the kernel socket in start_hci_dev. | 16:55 |
| luf | ... using g_io_add_watch_full | 16:55 |
| freemangordon | yes, you are right | 16:55 |
| freemangordon | anyway, can you just call the callback by hand? | 16:55 |
| freemangordon | the one that handles change_complete | 16:56 |
| freemangordon | or just call hci_read_local_name | 16:58 |
| freemangordon | (in hci.c) | 16:58 |
| freemangordon | and read_local_name_complete after that | 17:00 |
| freemangordon | (in hciops.c) | 17:00 |
| luf | It's all hack. I'm not sure if I may call the callback by hand. What when there is some callback. | 17:03 |
| luf | Shit how it can work even on PC. I don't understand. | 17:03 |
| freemangordon | which kernel? | 17:04 |
| luf | It doesn't matter. | 17:04 |
| freemangordon | it matters | 17:04 |
| luf | It depend on reading from socket ... | 17:04 |
| luf | Not on the kernel part as I understand. | 17:04 |
| freemangordon | it depends on the kernel to receive completion event | 17:05 |
| freemangordon | s/receive/send/ | 17:05 |
| infobot | freemangordon meant: it depends on the kernel to send completion event | 17:05 |
| freemangordon | mgmt that is | 17:05 |
| freemangordon | though I might be wrong | 17:06 |
| luf | I'm sorry I can continue in the evening. Now I have to finish some work and go home. | 17:07 |
| freemangordon | ok | 17:07 |
| luf | I'll try to send the read immediately after change or inquiry. | 17:07 |
| luf | But I may take a look into the BT kernel part :( to include it into some of next KP releases. | 17:08 |
| freemangordon | luf: we are talking about CSSU here, ain't? :P | 17:09 |
| luf | Yes about fixing problems with bluez. | 17:09 |
| freemangordon | hmm, I'll try to find zeq, it is time to start glibc/kernel stuff | 17:10 |
| kerio | yay kernel ^_^ | 17:10 |
| freemangordon | that way we can fix the kernel side too | 17:10 |
| kerio | hmm, does this mean that the mp will depend on the kernel? | 17:11 |
| kerio | :s | 17:11 |
| freemangordon | kerio: unfortunately it won't happen without glibc fallback patches | 17:11 |
| * freemangordon is afk too | 17:12 | |
| luf | freemangordon: I don't think it's good to do several changes in one step. | 17:12 |
| luf | What is mp ? | 17:13 |
| kerio | luf: otoh, flashing the kernel is kind of a big deal | 17:13 |
| kerio | luf: metapackage | 17:13 |
| kerio | mp-fremantle-community-pr | 17:13 |
| kerio | the thing that HAM checks to know what to upgrade | 17:13 |
| merlin1991 | luf: I didn't read the full backlog, but is the patch nuked again or still valid? | 17:13 |
| luf | merlin1991: what patch? | 17:14 |
| merlin1991 | bt name patch | 17:14 |
| luf | It's not fixing the root cause. So it works but isn't ideal. | 17:18 |
| merlin1991 | can we fix the root cause without touching the kernel? | 17:19 |
| luf | It has side effects right now because of change in kernel. | 17:24 |
| luf | So we can stay on bluez-4.60. If we want to upgrade to bluez-4.99 we need also kernel patch from my point of view. | 17:24 |
| luf | merlin1991: I'll investigate it more so maybe I can be wrong right now. | 17:26 |
| luf | And for sure I need to leave now. | 17:26 |
| *** luf has quit IRC | 17:28 | |
| *** fredrinLap has quit IRC | 17:37 | |
| *** fredrinLap has joined #maemo-ssu | 17:40 | |
| *** dhbiker has quit IRC | 18:03 | |
| *** luf has joined #maemo-ssu | 18:14 | |
| *** fredrinLap has quit IRC | 18:17 | |
| luf | freemangordon: bluez-4.60 also waits till the kernel returns OCF_CHANGE_LOCAL_NAME and then read the name. | 18:21 |
| *** andre__ has quit IRC | 18:29 | |
| luf | But for sure there is a "hack" for off mode 4.60 :D | 18:31 |
| luf | static int adapter_setup: | 18:31 |
| luf | adapter_ops->set_name(adapter->dev_id, name); | 18:31 |
| luf | if (g_str_equal(mode, "off")) | 18:31 |
| luf | strncpy((char *) adapter->dev.name, name, MAX_NAME_LENGTH); | 18:31 |
| *** fredrinLap has joined #maemo-ssu | 18:34 | |
| *** fredrinLap has quit IRC | 18:38 | |
| *** andre__ has joined #maemo-ssu | 18:41 | |
| kerio | freemangordon: are you the one that compiles busybox-power for -thumb? or is it iDont? | 18:57 |
| DocScrutinizer05 | my 2 cents: kernel-x.x.88 does eventA eventB sequence. $randomBTd rev 8 depends on that. Now somebody pulls in nice new patches to elevate $randomBTd to rev 9. Rev 9 expects new kernel API that does eevntB eventA now, instead of eventA eventB. | 18:58 |
| DocScrutinizer05 | It's NOT a good idea to elevate kernel API to match that $randomBTd rev9, since we will likely see other stuff break then | 18:59 |
| DocScrutinizer05 | so pretty please stay with kernl-x.x.88 API/ABI rather than elevating it to leete new kernel-x.y.99 | 19:00 |
| DocScrutinizer05 | rather backport $randomBTd rev9 patches to $randomBTd rev8 | 19:01 |
| DocScrutinizer05 | (obviously omitting those that cause the API change) | 19:02 |
| luf | DocScrutinizer05: :D | 19:03 |
| DocScrutinizer05 | or forward port the "borked" API details in $randomBTd rev9 from $randomBTd rev8 | 19:03 |
| luf | DocScrutinizer05: be sure we know your 2 cents ;) | 19:04 |
| *** toxaris has joined #maemo-ssu | 19:26 | |
| kerio | i'm pretty sure fmg /ignored me :( | 19:39 |
| *** Pali has joined #maemo-ssu | 19:40 | |
| luf | freemangordon: definitely the problem is in unread socket from bluetoothd side. | 19:59 |
| luf | It's a little bit better if I add g_main_context_iteration(NULL, FALSE); | 20:00 |
| luf | But it reads only one message per iteration and I have no idea right now how to read whole queue. | 20:01 |
| Pali | freemangordon, see code: https://meego.gitorious.org/~pali/meego-device-adaptation/pali-n900_libbme | 20:04 |
| Pali | I used socketpair instead pipe, because original libbme code returning pointer of socket | 20:04 |
| Pali | and application can read and write to socket | 20:05 |
| Pali | but from pipe only read (or write) | 20:05 |
| freemangordon | kerio: I was not here | 20:12 |
| kerio | excuses! | 20:13 |
| freemangordon | and yes, it is me to compile bb-power-thumb | 20:13 |
| kerio | :'( | 20:13 |
| kerio | i feel deeply hurt | 20:13 |
| kerio | only a busybox-power update could make me feel better | 20:13 |
| freemangordon | why? | 20:13 |
| freemangordon | aah :) | 20:13 |
| freemangordon | where is the source code? | 20:13 |
| freemangordon | Pali: hmm, iirc there was no need of socketpair, that is why i used pipes | 20:14 |
| freemangordon | though it should not matter | 20:14 |
| freemangordon | luf: but why only one message at a time? | 20:15 |
| freemangordon | I mean - what is the problem to read them all? | 20:15 |
| luf | Because of the callback function. | 20:15 |
| freemangordon | ? | 20:15 |
| freemangordon | callback gets called, you continue with the next | 20:15 |
| freemangordon | btw does it to select() on the socket? | 20:16 |
| freemangordon | s/it to/it do/ | 20:16 |
| infobot | freemangordon meant: btw does it do select() on the socket? | 20:16 |
| freemangordon | luf: IIRC there was a way to read only the first "packet" from a socket and reschedule | 20:17 |
| luf | freemangordon: no idea. it's glib stuff. One per iteration is because of the io_security_event. It reads only one message per the iteration (maybe due to minimum blocking). | 20:17 |
| freemangordon | lemme ask google | 20:17 |
| luf | I don't understand what are you thinking about. | 20:18 |
| luf | http://developer.gnome.org/glib/2.28/glib-IO-Channels.html#g-io-add-watch-full | 20:18 |
| luf | http://developer.gnome.org/glib/2.31/glib-The-Main-Event-Loop.html#g-main-context-iteration | 20:19 |
| freemangordon | thanks | 20:19 |
| luf | This detect there is something in the socket and call io_security_event (as defined with g_io_add_watch_full) | 20:19 |
| freemangordon | io_security_event is G_CALLBACK? | 20:20 |
| freemangordon | i'll check it myself | 20:20 |
| luf | Should be. | 20:20 |
| luf | static gboolean io_security_event(GIOChannel *chan, GIOCondition cond, gpointer data) | 20:20 |
| luf | Hmmm maybe: g_main_context_pending () :) | 20:21 |
| freemangordon | ;) | 20:22 |
| freemangordon | the fuck, what's wrong with my PC, paste still does not work :( | 20:22 |
| freemangordon | i'll logoff/logon, bbl | 20:22 |
| *** freemangordon has quit IRC | 20:22 | |
| *** freemangordon has joined #maemo-ssu | 20:25 | |
| luf | kerio: We're sorry but you're going to die :D | 20:26 |
| freemangordon | luf: g_main_context_pending won't do the job | 20:28 |
| luf | "while g_main_context_pending" do the job :) | 20:28 |
| luf | I hope | 20:28 |
| freemangordon | are you sure? | 20:29 |
| freemangordon | as IIRC you need ioctl(socket,FBIONREAD,&bytes_pending) | 20:29 |
| luf | Like a Fox. I want to believe :D | 20:29 |
| freemangordon | though I might forgotten how it works | 20:29 |
| freemangordon | well, lets hope then :D | 20:30 |
| luf | No. I'm not sure if it's ok to mix glib + direct access to the fd ... | 20:30 |
| freemangordon | me neither :) | 20:30 |
| freemangordon | DocScrutinizer05: now i remember that we found what the problem with wlan was. wifi switcher ;) | 20:31 |
| DocScrutinizer05 | hmß | 20:31 |
| DocScrutinizer05 | ?´ | 20:31 |
| DocScrutinizer05 | an appß | 20:32 |
| DocScrutinizer05 | DAMMIT? | 20:32 |
| DocScrutinizer05 | ???? | 20:32 |
| DocScrutinizer05 | ß?ß?ßßß???? | 20:32 |
| freemangordon | the guy had uninstalled wifi switcher (or whatever was the name) and no wlan after that | 20:32 |
| kerio | ßßßßßßßßßßßßßßßßßß | 20:32 |
| DocScrutinizer05 | an app?` | 20:32 |
| freemangordon | yes | 20:32 |
| DocScrutinizer05 | fair enough | 20:32 |
| freemangordon | "If I manually start icd2 as root as daemon (or with upstart) and disable & enable internet via wifi switcher. then it works." | 20:33 |
| DocScrutinizer05 | many thanks for sharing that historic bit of info ;-) | 20:33 |
| freemangordon | http://talk.maemo.org/showpost.php?p=1270059&postcount=776 | 20:33 |
| DocScrutinizer05 | ok, seems that's absolutely the story to explain that | 20:33 |
| freemangordon | yeah. thuough I cannot get it why this guy refuses to reflash | 20:34 |
| DocScrutinizer05 | I declare auto-disconnect deprectaed since years now, literally. All those hackers messing with ICD seem to have no real clue | 20:34 |
| freemangordon | ar was it auto-disconnect? | 20:34 |
| freemangordon | *or | 20:35 |
| *** fredrinLap has joined #maemo-ssu | 20:35 | |
| freemangordon | not sure, but it was either of those | 20:35 |
| DocScrutinizer05 | some bullshit to tear down GPRS/WLAN after some time of no traffic | 20:35 |
| DocScrutinizer05 | wifi switcher might be same class of fsckdup BS | 20:35 |
| freemangordon | yeah, but I am not 100% sure which was the application to blame, auto-disconnect or wifi-switcher | 20:36 |
| freemangordon | yeah | 20:36 |
| DocScrutinizer05 | could those poor misguided lusers apt-get purge ICD2 ? | 20:37 |
| DocScrutinizer05 | the reinstall | 20:37 |
| DocScrutinizer05 | then | 20:37 |
| freemangordon | NFC | 20:37 |
| freemangordon | kerio: where is the source code of bb-power-thumb? | 20:39 |
| freemangordon | (new version) | 20:39 |
| kerio | freemangordon: dunno, hold on | 20:39 |
| freemangordon | tadzik: ping | 20:39 |
| freemangordon | kerio: ok. usually iDint send it via mail to me ;) | 20:39 |
| kerio | http://repository.maemo.org/extras-devel/pool/fremantle/free/source/b/busybox-power/busybox-power_1.20.2power2.tar.gz | 20:39 |
| freemangordon | *iDont | 20:39 |
| kerio | sounds legit | 20:40 |
| freemangordon | kerio: come on | 20:40 |
| kerio | what? | 20:40 |
| freemangordon | it needs -thumbN suffix and such | 20:40 |
| kerio | oh so you didn't /ignore me but you do ignore me :'( | 20:40 |
| * kerio points at the file extension | 20:40 | |
| freemangordon | that is what iDont do before sending it to me, pester him, not me | 20:41 |
| *** _ade_ has joined #maemo-ssu | 20:41 | |
| freemangordon | _ade_: hi | 20:41 |
| _ade_ | hi | 20:41 |
| freemangordon | you could safely ignore these warnings | 20:41 |
| freemangordon | :) | 20:41 |
| _ade_ | okay, you get them too? | 20:41 |
| freemangordon | yes | 20:42 |
| freemangordon | the reason for them is: | 20:42 |
| freemangordon | linker thinks (for some reason) that object is hardfp, but as it is softfp assertion fails | 20:42 |
| freemangordon | but produced binary is ok | 20:43 |
| _ade_ | one other question: should non-thumb configs also be described for gcc 47? | 20:43 |
| freemangordon | you may try to pass -mfloat-abi=softfp for your test, to see if it changes the result | 20:44 |
| freemangordon | _ade_: rephrase please | 20:44 |
| freemangordon | configs? | 20:44 |
| _ade_ | well, thumb is not supported on non thumbs kernel, or? | 20:44 |
| luf | freemangordon: you're right. pending isn't what I need. | 20:45 |
| freemangordon | thumb is supported as it is MPU ISA, but it will blow in your face if a kernel without workarounds is booted. But gcc4.7.2 does not produce thumb binaries by default, you should pass -mthumb if you want it | 20:46 |
| kerio | freemangordon: hm, you just need to add a new entry in the changelog and add the dep | 20:46 |
| _ade_ | okay, that can explain the (larger) sizes I see | 20:46 |
| freemangordon | _ade_:without -mthumb it produces regular ARM ELFs | 20:47 |
| freemangordon | kerio: no, it is maintainer job to do it | 20:47 |
| _ade_ | now I understand that | 20:47 |
| kerio | freemangordon: hm | 20:47 |
| _ade_ | freemangordon: yet another question: are compiler flags different? | 20:47 |
| kerio | freemangordon: really though, it's exactly the same thing you do for other packages | 20:48 |
| freemangordon | _ade_: you may want to explore the other goodies: -mfpu=neon -ftree-vectorize -fgraphite -lto | 20:48 |
| freemangordon | _ade_: some flags differ. and gcc 4.7.2 has much strict syntax etc. checking | 20:48 |
| kerio | hm, what's graphite? | 20:48 |
| _ade_ | freemangordon: thanks for explaining this. I could put some remarks about that in the wiki. Got to go work now, sorry | 20:50 |
| freemangordon | _ade_: thanks, np | 20:50 |
| freemangordon | kerio: http://gcc.gnu.org/wiki/Graphite | 20:50 |
| kerio | polyhedral optimization? | 20:51 |
| kerio | wtf | 20:51 |
| freemangordon | http://gcc.gnu.org/wiki/Graphite/Parallelization | 20:51 |
| freemangordon | luf: see now? why we don;t trust you :P | 20:52 |
| freemangordon | luf: one should read the socket until there is no more datat IIRC | 20:52 |
| luf | Why? I se no reason :D | 20:52 |
| luf | *see | 20:53 |
| freemangordon | now my paste works, lemme try to find something useful | 20:53 |
| freemangordon | luf: do you know where the socket is read? | 20:53 |
| luf | freemangordon: It's clear for me from the beginning. The question is how. I'll find the way ;) | 20:53 |
| kerio | luf: you fail at unix forever :'( | 20:53 |
| freemangordon | luf: ioctl(socket,...) | 20:54 |
| luf | kerio: really? :D | 20:54 |
| freemangordon | the one I wrote | 20:54 |
| kerio | reading a socket isn't guaranteed to return jack shit | 20:54 |
| luf | freemangordon: yes without B ;) | 20:54 |
| freemangordon | kerio: read what I wrote again | 20:54 |
| luf | freemangordon: it's read in the callback function | 20:55 |
| luf | But you don't want to put the loop there. For sure. | 20:55 |
| freemangordon | kerio: ioctl (socket,FIONREAD,&bytes_available) | 20:55 |
| luf | freemangordon: I'm compiling and I'll test. | 20:55 |
| freemangordon | luf: not there, return bytes avalable and check for 0 | 20:56 |
| luf | I hoped there is some function for it in glib ... | 20:56 |
| *** arcean_ has joined #maemo-ssu | 20:56 | |
| luf | freemangordon: I know ;) | 20:56 |
| freemangordon | and there MUST be some function in glib for calling a callback | 20:56 |
| freemangordon | (g-timer?) :P | 20:56 |
| luf | It's the iteration ... | 20:56 |
| freemangordon | g_timer | 20:56 |
| luf | Bleeee. | 20:57 |
| luf | forget about such shit :) | 20:57 |
| *** arcean has quit IRC | 20:58 | |
| freemangordon | luf: g_main_context_invoke? | 20:58 |
| *** _ade_ has quit IRC | 20:58 | |
| freemangordon | I bet that will do the job | 20:59 |
| luf | Nope. I already sent it | 20:59 |
| luf | g_main_context_iteration | 20:59 |
| freemangordon | sent what? | 20:59 |
| freemangordon | noo, g_main_context_invoke | 20:59 |
| freemangordon | check if you have pending bytes to read at the end of callback | 20:59 |
| freemangordon | and do g_main_context_invoke on callback | 20:59 |
| freemangordon | (if there are still bytes) | 21:00 |
| Pali | freemangordon, I will create new kp pre52 build | 21:00 |
| luf | Understand. | 21:00 |
| freemangordon | luf: or maybe g_main_context_invoke_full if you want to play with priorities | 21:00 |
| freemangordon | Pali: what has changed? | 21:00 |
| luf | FALSE | 21:01 |
| freemangordon | luf: what is FALS? | 21:01 |
| luf | Note that, as with normal idle functions, function should probably return FALSE. If it returns TRUE, it will be continuously run in a loop (and may prevent this call from returning). | 21:01 |
| Pali | some changes in rx51_battery and bq2415x_charger drivers + enabled some iptables/ipv6 modules | 21:01 |
| freemangordon | Pali: great | 21:01 |
| Pali | and sigmask patch | 21:01 |
| freemangordon | aah, yes | 21:01 |
| freemangordon | :D | 21:01 |
| luf | The function usually returns TRUE ;) so invoke isn't such win. | 21:02 |
| freemangordon | hmm , i will send a mail to zeq tomorrow, it's been too long he is missing | 21:02 |
| freemangordon | luf: then return TRUE until there are no more bytes to read | 21:02 |
| Pali | btw, can merlin1991 import/promote packages in package interface? | 21:03 |
| freemangordon | I *think* he still cannot | 21:03 |
| merlin1991 | let me check | 21:03 |
| luf | freemangordon: Ee = no. It calls stop_hci_dev(index); prior to return FALSE. And it's for sure isn't what I want. | 21:04 |
| freemangordon | luf: sorry to ask again, which function is that? | 21:05 |
| luf | An in case EAGAIN it returns TRUE. | 21:05 |
| luf | io_security_event | 21:05 |
| freemangordon | ok | 21:05 |
| merlin1991 | maemo.org is slow :/ | 21:05 |
| *** fredrinLap has quit IRC | 21:07 | |
| DocScrutinizer05 | http://wiki.maemo.org/Community_SSU/known_broken_packages | 21:08 |
| luf | Shit I compiled wrong version :D | 21:09 |
| DocScrutinizer05 | add fapman there if you take joy in it | 21:09 |
| DocScrutinizer05 | don't ask me why I've put it under Community_SSU/ | 21:11 |
| luf | freemangordon: I thinking more about it and maybe reading the queue isn't a win as it can ends with stop_hci_dev ... | 21:12 |
| merlin1991 | Pali: I still can't | 21:12 |
| *** fredrinLap has joined #maemo-ssu | 21:12 | |
| Pali | ok | 21:13 |
| freemangordon | luf: it won't stop if you check if there is anything to read prior to read() | 21:13 |
| luf | freemangordon: there should be also another event in queue ... | 21:13 |
| *** chainsawbike has quit IRC | 21:14 | |
| freemangordon | luf: if you recursively call io_security_event with check if there is anything to read in case of G_IO_IN, everything will work ok | 21:14 |
| *** chainsawbike has joined #maemo-ssu | 21:15 | |
| freemangordon | or wrap io_security_event and do g_main_context_invoke on the wrapper | 21:16 |
| *** nox- has joined #maemo-ssu | 21:16 | |
| DocScrutinizer05 | ~broken | 21:17 |
| infobot | methinks broken is mailto:nothing@machine.cx -> http://machine.cx/debian/ or screen shots are at http://nivda.machine.cx or that's sid for you. | 21:17 |
| DocScrutinizer05 | ~broken-maemo | 21:18 |
| DocScrutinizer05 | ~broken-maemo is http://wiki.maemo.org/Community_SSU/known_broken_packages see this list for deprecated known borked packages | 21:18 |
| infobot | DocScrutinizer05: okay | 21:18 |
| kerio | DocScrutinizer05: wait, "not running preinst"? | 21:19 |
| kerio | what the fuck | 21:19 |
| luf | while (ioctl(dev->sk, FIONREAD, &bytes) == 0 && bytes > 0) - doesn't work. | 21:19 |
| freemangordon | not work as in? | 21:20 |
| freemangordon | also maybe you need g_io_channel_unix_get_fd(chan); | 21:21 |
| luf | Yes. It never goes into the loop. | 21:21 |
| freemangordon | what is dev->sk? | 21:21 |
| luf | I have no channel in the function. dev->sk is the fd to which is the hci_send_cmd sent. | 21:22 |
| luf | So it's the right fd. | 21:22 |
| freemangordon | are you sure there is only one fd for read and write? | 21:23 |
| luf | Maybe AF_BLUETOOTH doesn't implement such ioctl call. | 21:23 |
| freemangordon | hmm, could be | 21:23 |
| luf | chan = g_io_channel_unix_new(dev->sk); - yes I'm sure. | 21:25 |
| freemangordon | luf: according to google it is implemented | 21:25 |
| freemangordon | FIONREAD | 21:26 |
| freemangordon | what is errno? | 21:26 |
| luf | I didn't log it. | 21:26 |
| luf | * errno | 21:26 |
| freemangordon | yeah | 21:26 |
| freemangordon | the fuck, that should work :( | 21:26 |
| *** fredrinLap has quit IRC | 21:27 | |
| luf | Is it implemented in 2.6.28? I'm using KP51 (since yesterday). | 21:27 |
| DocScrutinizer05 | kerio: well, maybe running preinst, but to no effect since not showing the requesters in there | 21:27 |
| freemangordon | luf: it should be, lemme check the source | 21:28 |
| DocScrutinizer05 | kerio: it's a rough draft | 21:28 |
| DocScrutinizer05 | kerio: ...and a wiki anyway | 21:28 |
| *** dhbiker has joined #maemo-ssu | 21:30 | |
| DocScrutinizer05 | ~lart merlin for wasting percious time on #harmattan / N9-development | 21:33 |
| * infobot steals merlin's mojo for wasting percious time on #harmattan / N9-development | 21:33 | |
| merlin1991 | ~lart DocScrutinizer05 for larting in general | 21:33 |
| * infobot lowers DocScrutinizer05's priority for larting in general | 21:34 | |
| DocScrutinizer05 | look how smart she's with grammar | 21:34 |
| merlin1991 | DocScrutinizer05: so you have more reasons for you lart: https://metalab.at/wiki/Hack-A-N9 | 21:35 |
| DocScrutinizer05 | eew, I don't even dare to click that URL | 21:35 |
| freemangordon | luf: what about while(read()== HCI_MAX_EVENT_SIZE)? | 21:35 |
| DocScrutinizer05 | since there are no reasonable hacks that can be done to a N9 | 21:35 |
| freemangordon | I hope events are equal sizes | 21:36 |
| freemangordon | hmm, is it possible that we hist pselect() bug? | 21:37 |
| freemangordon | *hit | 21:37 |
| luf | freemangordon: are you even more crazy me? I can't read messages ... Or do I miss something? | 21:37 |
| freemangordon | luf: I am deffinitely more crazy than you :D | 21:38 |
| freemangordon | what do you want me to explain | 21:38 |
| freemangordon | ? | 21:38 |
| luf | how ioctl bullshit can depend on pselect? | 21:38 |
| freemangordon | luf: we are missing a callback call, correct? | 21:39 |
| freemangordon | which is not missed in 4.60 | 21:39 |
| luf | I don't think so. | 21:39 |
| luf | There is mode = "off" hack as I sent today ... | 21:39 |
| freemangordon | aaah, yes | 21:40 |
| freemangordon | luf: sory, I am stupid :) | 21:40 |
| freemangordon | *sorry | 21:40 |
| luf | No you're definitely not stupid. You work on several tasks at same time. I work only on one ;) | 21:40 |
| freemangordon | then why the hell we are losing our time when nokia is doing the same ugly hack? | 21:40 |
| freemangordon | that is why ^^^ | 21:41 |
| luf | I'm imbecil. I forgot to debug errno . I debug return value (-1) and bytes ... shit. | 21:41 |
| freemangordon | (I am stupid ) | 21:41 |
| luf | Because we're better. | 21:41 |
| luf | And it takes some time to my HF to get the operator name so maybe something isn't as good as it should be ;) | 21:42 |
| freemangordon | luf: scratch that, if it is workarounded in the same way in stock, do it the same way and forget | 21:42 |
| luf | We're real man :D | 21:42 |
| freemangordon | hehe | 21:42 |
| luf | But the changes are too huge to be sure. | 21:42 |
| luf | BTW I need to destroy the wall using my head ;) | 21:44 |
| freemangordon | what's wrong with the wall? | 21:44 |
| luf | Just it exists :D | 21:44 |
| freemangordon | aah, i understand now. go on then :D | 21:45 |
| luf | And not set BT name. You know ... | 21:45 |
| luf | And at last (not at least) someone said me: don't do it :D | 21:46 |
| *** fredrinLap has joined #maemo-ssu | 21:46 | |
| freemangordon | DocScrutinizer05: http://talk.maemo.org/showpost.php?p=1270100&postcount=778 | 21:49 |
| freemangordon | LOL | 21:49 |
| DocScrutinizer05 | LOL indeed - 2somehow commented out" W*T*F! | 21:51 |
| freemangordon | luf: what now? | 21:54 |
| luf | errno 22 | 21:54 |
| freemangordon | eaccess? hmm, lemme check | 21:54 |
| luf | errno of 22 (Invalid Argument) | 21:55 |
| luf | Are you sure EACCESS? | 21:55 |
| freemangordon | aah | 21:55 |
| freemangordon | no | 21:55 |
| freemangordon | i was going to check | 21:55 |
| freemangordon | well, it seems it is not supported for AF_BLUETOOTH | 21:55 |
| luf | /usr/include/asm-generic/errno-base.h:#defineEACCES13/* Permission denied */ | 21:55 |
| freemangordon | ok, ok | 21:56 |
| luf | #defineEINVAL22/* Invalid argument */ | 21:56 |
| freemangordon | OK | 21:56 |
| freemangordon | :D | 21:56 |
| luf | :D | 21:56 |
| freemangordon | well, there are 2 options AIUI: | 21:56 |
| freemangordon | 1. use the same trick nokia did | 21:56 |
| luf | It's not nokia's trick. It's old bluez trick. | 21:57 |
| freemangordon | 2. read until there is no more data (if the socket is NONBLOCK) | 21:57 |
| freemangordon | I vote for 1 | 21:57 |
| luf | 2) how to check whan I can't read from it? | 21:57 |
| luf | That's still the same question from begining :D | 21:58 |
| freemangordon | you don't need to, read will return !=HCI_MAX_EVENT_SIZE | 21:59 |
| luf | Shit I see the possibility. I'm stupid bad guy (let me check ... yes I'm guy) :D | 21:59 |
| freemangordon | luf: though make a note that this is MAX | 21:59 |
| luf | I can test errno after the callback :) | 21:59 |
| DocScrutinizer05 | errwut? reading a queue after waiting for signal/callback? that'S a standard pattern, used all over the place | 22:02 |
| freemangordon | yes | 22:02 |
| freemangordon | ;) | 22:03 |
| freemangordon | the question is why it is not implemented in bluez | 22:03 |
| DocScrutinizer05 | since bluez obviously written by idiots, otherwise I don't see how using /etc/machinefoo as a semaphore file could come in | 22:03 |
| DocScrutinizer05 | *IF* you're using semaphore files, FFS do that in /var/run or similar location, *NOT* in /etc/ | 22:05 |
| freemangordon | luf: I think it won't work, frames have different sizes, without len member in the struct | 22:05 |
| freemangordon | so it will be very hard to process all the frames in the queue | 22:06 |
| luf | (08:59:54 PM) luf: I can test errno after the callback :) | 22:06 |
| freemangordon | so? | 22:06 |
| freemangordon | how does it help, elaborate please, I don;t get it | 22:06 |
| DocScrutinizer05 | freemangordon: WUT?????????? dafaq architects losz last synapse | 22:06 |
| freemangordon | DocScrutinizer05: seems so | 22:07 |
| luf | freemangordon: If there is nothing to read it should put EAGAIN into errno. | 22:07 |
| freemangordon | luf: but that is after first unsuccessful read AFAIK | 22:08 |
| luf | There is no function call after it so I think I can test it. | 22:08 |
| luf | Yes. It's what I want ;) | 22:08 |
| DocScrutinizer05 | freemangordon: not even implicit len, via msg identifier or sth? | 22:09 |
| freemangordon | DocScrutinizer05: see hci_send_req, they find next frame by adding the size depending on the current frame type | 22:09 |
| freemangordon | (plush header) | 22:10 |
| freemangordon | *plus | 22:10 |
| freemangordon | :( | 22:10 |
| freemangordon | DocScrutinizer05: aah, no | 22:11 |
| freemangordon | My mistake, hci_event_hdr has plen member | 22:11 |
| freemangordon | luf: ^^^ | 22:11 |
| * DocScrutinizer05 waves and heads out for a pretty well earned friday eve booze | 22:12 | |
| freemangordon | luf: see what they do in see hci_send_req, the same should happen in io_security_event | 22:13 |
| freemangordon | luf: isn't hci_send_req a better place for setting the name? | 22:14 |
| luf | It's not called for such thing. The hci_send_cmd is the same code as in 4.60 ... | 22:16 |
| freemangordon | ok | 22:16 |
| luf | BTW check for EAGAIN isn't good option :D | 22:16 |
| luf | I have no running bluetoothd now :D | 22:17 |
| freemangordon | anyway, i'll try to fix the packaging. And I recommend you to use option 1 ;) | 22:17 |
| luf | :D | 22:18 |
| luf | Option 1 is still at web ;) | 22:18 |
| luf | Fuck it's not non-blocking :) So it blocks at the read :) | 22:22 |
| freemangordon | great :D | 22:22 |
| freemangordon | well, options were reduced :D | 22:22 |
| luf | No idea why they check EAGAIN :D | 22:22 |
| freemangordon | blocking call can be interrupted IIRC | 22:23 |
| freemangordon | don't ask me when and why | 22:23 |
| luf | Some interrupt or signal or something like that. | 22:24 |
| luf | Fuck how the glib checks it? | 22:24 |
| freemangordon | select | 22:24 |
| luf | freemangordon: true select or poll. | 22:35 |
| freemangordon | should be true select | 22:35 |
| freemangordon | not sure of course | 22:36 |
| luf | Ok, option 1 :D | 22:38 |
| freemangordon | :D | 22:38 |
| luf | As usual the wall is harder than my head :) | 22:39 |
| luf | So I'm leaving today ... bye | 22:45 |
| freemangordon | bye | 22:45 |
| *** luf has quit IRC | 22:45 | |
| *** NIN101 has quit IRC | 23:19 | |
| *** andre__ has quit IRC | 23:23 | |
| kerio | DocScrutinizer05: http://talk.maemo.org/showpost.php?p=1270176&postcount=300 lololololo | 23:52 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!