| 01:24.40 | *** join/#maemo-ssu ekze (~nyan@bakaekze.ru) |
| 02:27.15 | *** join/#maemo-ssu amiconn_ (quassel@rockbox/developer/amiconn) |
| 03:44.56 | *** join/#maemo-ssu DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg) |
| 05:18.13 | kerio | goddammit i needed fmg :( |
| 05:54.58 | *** join/#maemo-ssu M13 (~Miranda@83.149.38.60) |
| 06:02.44 | *** join/#maemo-ssu freemangordon (~freemango@130-204-50-168.2074221835.ddns.cablebg.net) |
| 06:17.01 | *** join/#maemo-ssu _rd (~rd@p57B495A4.dip0.t-ipconnect.de) |
| 06:22.46 | *** join/#maemo-ssu luf (luf@nat/ibm/x-ijapstuzpxfbtzlq) |
| 06:33.12 | *** join/#maemo-ssu povbot (~supybot@office.pov.lt) |
| 06:33.12 | *** mode/#maemo-ssu [+v povbot] by ChanServ |
| 07:18.47 | *** join/#maemo-ssu ekze (~nyan@bakaekze.ru) |
| 07:24.35 | *** join/#maemo-ssu X-Fade (~xfade@d5152FFD8.static.telenet.be) |
| 08:39.39 | *** join/#maemo-ssu arcean (~Arcean@aaeo98.neoplus.adsl.tpnet.pl) |
| 08:51.47 | *** join/#maemo-ssu M4rtinK (~M4rtinK@mail.melf.eu) |
| 09:05.37 | *** join/#maemo-ssu wmarone_ (~wmarone@c-67-174-151-253.hsd1.ca.comcast.net) |
| 09:08.27 | *** join/#maemo-ssu toxaris (~toxaris@s83-180-246-172.cust.tele2.se) |
| 09:27.10 | *** join/#maemo-ssu arcean_ (~Arcean@aaet62.neoplus.adsl.tpnet.pl) |
| 10:21.00 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 10:24.41 | *** join/#maemo-ssu lizardo (lizardo@nat/indt/x-oxrexmptoqnehrxg) |
| 11:40.34 | luf | freemangordon: ping |
| 12:10.21 | *** join/#maemo-ssu fredrinLap (~fn@cm-84.208.108.15.getinternet.no) |
| 12:20.54 | freemangordon | luf: pong |
| 12:29.50 | luf | freemangordon: I'm uploading new version and the patch to the merlin1991. |
| 12:30.41 | luf | I want also something else but I forget it :( |
| 12:30.47 | freemangordon | luf: may I see the patch? |
| 12:31.03 | luf | Sure. |
| 12:31.32 | freemangordon | luf: write those down, and hope you'l not forget that you wrote it. And where :P |
| 12:31.47 | luf | :D Sure. |
| 12:32.07 | freemangordon | it the patch somewhere in github/gitorious? |
| 12:32.17 | freemangordon | pastebin? |
| 12:32.48 | luf | Nope. MMNT |
| 12:32.56 | freemangordon | ok :) |
| 12:35.17 | luf | http://merlin1991.at/~luf/bluez/source/221_name_init.patch |
| 12:36.16 | luf | I don't like it very much but it works. |
| 12:36.28 | freemangordon | hehe |
| 12:36.46 | luf | I'll upload also logs so you can take a look what happens in N900 ;) |
| 12:36.47 | freemangordon | why didn't you implement that on ON? |
| 12:36.57 | freemangordon | but on OFF |
| 12:36.59 | luf | You'll see in logs. |
| 12:37.03 | freemangordon | aah, ok |
| 12:37.05 | luf | MMNT @work |
| 12:37.53 | luf | I received some request so I have to focus on that right now. |
| 12:38.04 | freemangordon | ok, no hurry |
| 12:38.27 | luf | The reason is that the answer from kernel comes after the BT dev is changed to state DOWN (if down is default). |
| 12:38.59 | freemangordon | hmm, and what 4.60 does? |
| 12:39.00 | luf | When the BT device is by default on it stays on and the answer from kernel is processed well. |
| 12:39.11 | luf | Nothing like that :) |
| 12:39.18 | freemangordon | :) |
| 12:39.31 | luf | Huge rework in name ... as it's splitted to adapter name and device name in 4.99. |
| 12:39.41 | freemangordon | I see |
| 12:40.13 | freemangordon | well, I agree the patch looks ugly, but as long as it works (and merlin1991 approves it) it should be ok |
| 12:40.32 | freemangordon | i'll try to fix packaging later |
| 12:42.11 | luf | I don't understand why the kernel answer is postponed :( |
| 12:42.44 | freemangordon | hmm, could it be that the queue is not processed? |
| 12:44.00 | freemangordon | i.e. noone reads the socket when there is a message |
| 12:45.40 | luf | freemangordon: possible. But I don't see it in the source code. |
| 12:46.21 | luf | logs uploaded. |
| 12:46.48 | luf | merlin1991.at/~luf/bluez/logs |
| 12:47.40 | luf | freemangordon: the patch is like hammer. It fix only the situation when no name initialized when booting with by default disabled BT device. |
| 12:48.43 | freemangordon | yeah, I see |
| 12:48.45 | 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. |
| 12:49.46 | luf | syslog.bluez_4.99.devoff - booting with BT disabled by default |
| 12:50.02 | luf | syslog.bluez_4.99.devon - booting with BT enabled by default |
| 12:50.11 | freemangordon | luf: but why there is this: |
| 12:50.18 | luf | syslog.bluez_4.99.fixed_btname_v1 - booting with BT disabled by default with the patch |
| 12:50.26 | kerio | freemangordon: btw busybox-power was updated |
| 12:50.42 | kerio | no versioning issue for that |
| 12:50.43 | freemangordon | the fuck, paste don't work :( |
| 12:51.03 | luf | freemangordon: :) |
| 12:51.20 | freemangordon | ok, i'll write it |
| 12:51.22 | luf | feel free to write filename and line number ;) |
| 12:51.46 | freemangordon | 'Setting name Luf - Nokia N900' |
| 12:51.54 | freemangordon | in devoff file |
| 12:52.28 | luf | It's trying to set the name and send it into kernel. But the answer returned after HCI dev down. |
| 12:52.37 | freemangordon | aaah, I see |
| 12:53.02 | freemangordon | luf: i'll have a look into the code |
| 12:53.17 | luf | I traced it down to hci_send_command (plugins/hciops.c:hciops_set_name() OCF_CHANGE_LOCAL_NAME: sent Luf - Nokia N900) |
| 12:53.27 | freemangordon | yes |
| 12:53.33 | freemangordon | I saw that |
| 12:53.37 | luf | answer is: plugins/hciops.c:cmd_complete() OCF_CHANGE_LOCAL_NAME: index 0 status 0 |
| 12:53.48 | freemangordon | ok |
| 12:53.52 | luf | below: HCI dev 0 down |
| 12:53.57 | luf | That's the problem. |
| 12:54.05 | freemangordon | ok, got it |
| 12:54.33 | luf | There is no "HCI dev 0 down" when BT device is enabled by default so the name is set as expected. |
| 12:55.05 | luf | No idea why plugins/hciops.c:io_security_event is postponed (it's some callback). |
| 13:06.02 | *** join/#maemo-ssu NIN101 (~NIN@93.210.137.122) |
| 13:13.16 | 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); |
| 13:18.37 | freemangordon | luf: it seems kernel is missing a call to hci_req_complete |
| 13:19.00 | freemangordon | for HCI_OP_WRITE_LOCAL_NAME |
| 13:19.13 | freemangordon | nwer kernels have it |
| 13:19.16 | freemangordon | *newer |
| 13:21.05 | freemangordon | hmm, actually kernel is missing LOTS OF code, I wonder how this works at all :D |
| 13:29.12 | freemangordon | luf: I think I have a better idea |
| 13:29.29 | luf | Shit. I don't want to patch kernel ... but maybe I should :( |
| 13:29.36 | freemangordon | instead of using "the hammem" |
| 13:29.38 | freemangordon | no,no |
| 13:29.40 | luf | freemangordon: I'm listening. |
| 13:29.48 | freemangordon | we won't touch the kernel |
| 13:29.51 | freemangordon | so,... |
| 13:29.57 | luf | Why not? |
| 13:29.59 | luf | :) |
| 13:30.03 | freemangordon | hehe |
| 13:30.06 | freemangordon | so,... |
| 13:30.24 | luf | It should go into KP52 or KP53 ... |
| 13:30.29 | freemangordon | call OCF_READ_LOCAL_NAME |
| 13:30.43 | freemangordon | after the call OCF_CHANGE_LOCAL_NAME |
| 13:31.03 | freemangordon | that way we will mimic the expected behaviour |
| 13:31.14 | luf | I don't understand what do you mean with call OCF_READ_LOCAL_NAME? |
| 13:31.32 | freemangordon | fuuck, why copy/paste don't work |
| 13:31.37 | freemangordon | stupid remmina :( |
| 13:31.48 | luf | Aaah hci_send_cmd ... I get it. |
| 13:31.56 | freemangordon | yes |
| 13:32.26 | luf | so OCF_READ_LOCAL_NAME + OCF_CHANGE_LOCAL_NAME + inquiry ? |
| 13:32.35 | freemangordon | the opposite |
| 13:32.41 | freemangordon | first change and the read |
| 13:32.57 | luf | Ahhh sorry my mistake. |
| 13:33.00 | freemangordon | or change + inquiry (i don't know what inquiry does) |
| 13:33.12 | luf | Ok. I'll try it. |
| 13:33.41 | freemangordon | luf, I don't know what completion comes on device off |
| 13:33.50 | freemangordon | but it is not for name change AIUI |
| 13:34.14 | luf | where did you find missing hci_req_complete ? |
| 13:34.40 | freemangordon | my point was 1. change 2. read 3. immediately use the name from the kernel |
| 13:34.59 | *** join/#maemo-ssu dafox (~dafox@ip51cc571d.speed.planet.nl) |
| 13:35.15 | freemangordon | that way if kernel change operation has failed for some reason , your read will return blank |
| 13:35.30 | freemangordon | (and it will be the same as change complete never comes) |
| 13:35.44 | freemangordon | luf: in internet, newer kernels |
| 13:36.09 | freemangordon | look for hci_cc_write_local_name |
| 13:36.15 | freemangordon | google for ^^^ |
| 13:38.18 | freemangordon | luf: AIUI the complition is first found in 3.0 |
| 13:38.34 | freemangordon | mgmt_set_local_name_complete ;) |
| 13:38.38 | freemangordon | kernel function |
| 13:43.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. |
| 13:44.44 | freemangordon | you mean the you cannot get the result from "read"? |
| 13:45.33 | luf | I think so. |
| 13:45.52 | luf | But I should be wrong. |
| 13:48.52 | freemangordon | luf: damn, code does exactly this :D |
| 13:49.05 | freemangordon | look in hciops.c |
| 13:49.20 | freemangordon | cmd_complete() |
| 13:49.31 | luf | Yes I know. |
| 13:49.52 | luf | But it waits for the kernel response which come so late. |
| 13:50.05 | luf | I think you want to send it ASAP :) |
| 13:50.33 | freemangordon | luf: it wait for response that never comes |
| 13:50.41 | freemangordon | *waits |
| 13:50.46 | freemangordon | AIUI |
| 13:50.56 | freemangordon | no matter on/off trickery |
| 13:51.05 | luf | It comes after the dev is down. |
| 13:51.12 | freemangordon | look at mgmt_handle_event |
| 13:51.20 | luf | what file? |
| 13:51.30 | freemangordon | main.c |
| 13:52.31 | freemangordon | though I might be wrong |
| 13:53.21 | luf | Why this file? |
| 13:54.05 | freemangordon | well, i'll check the logs once again, maybe I miss something |
| 13:54.29 | luf | It read the result using: io_security_event from plugins/hicops.c |
| 13:55.06 | luf | And it's assigned as callback for the kernel socket in start_hci_dev. |
| 13:55.18 | luf | ... using g_io_add_watch_full |
| 13:55.33 | freemangordon | yes, you are right |
| 13:55.56 | freemangordon | anyway, can you just call the callback by hand? |
| 13:56.09 | freemangordon | the one that handles change_complete |
| 13:58.10 | freemangordon | or just call hci_read_local_name |
| 13:58.22 | freemangordon | (in hci.c) |
| 14:00.21 | freemangordon | and read_local_name_complete after that |
| 14:00.40 | freemangordon | (in hciops.c) |
| 14:03.31 | luf | It's all hack. I'm not sure if I may call the callback by hand. What when there is some callback. |
| 14:03.48 | luf | Shit how it can work even on PC. I don't understand. |
| 14:04.00 | freemangordon | which kernel? |
| 14:04.06 | luf | It doesn't matter. |
| 14:04.15 | freemangordon | it matters |
| 14:04.16 | luf | It depend on reading from socket ... |
| 14:04.40 | luf | Not on the kernel part as I understand. |
| 14:05.08 | freemangordon | it depends on the kernel to receive completion event |
| 14:05.24 | freemangordon | s/receive/send/ |
| 14:05.50 | freemangordon | mgmt that is |
| 14:06.16 | freemangordon | though I might be wrong |
| 14:07.33 | luf | I'm sorry I can continue in the evening. Now I have to finish some work and go home. |
| 14:07.42 | freemangordon | ok |
| 14:07.59 | luf | I'll try to send the read immediately after change or inquiry. |
| 14:08.42 | luf | But I may take a look into the BT kernel part :( to include it into some of next KP releases. |
| 14:09.12 | freemangordon | luf: we are talking about CSSU here, ain't? :P |
| 14:09.47 | luf | Yes about fixing problems with bluez. |
| 14:10.44 | freemangordon | hmm, I'll try to find zeq, it is time to start glibc/kernel stuff |
| 14:10.55 | kerio | yay kernel ^_^ |
| 14:10.59 | freemangordon | that way we can fix the kernel side too |
| 14:11.16 | kerio | hmm, does this mean that the mp will depend on the kernel? |
| 14:11.17 | kerio | :s |
| 14:11.29 | freemangordon | kerio: unfortunately it won't happen without glibc fallback patches |
| 14:12.12 | freemangordon | is afk too |
| 14:12.25 | luf | freemangordon: I don't think it's good to do several changes in one step. |
| 14:13.28 | luf | What is mp ? |
| 14:13.33 | kerio | luf: otoh, flashing the kernel is kind of a big deal |
| 14:13.36 | kerio | luf: metapackage |
| 14:13.40 | kerio | mp-fremantle-community-pr |
| 14:13.50 | kerio | the thing that HAM checks to know what to upgrade |
| 14:13.51 | merlin1991 | luf: I didn't read the full backlog, but is the patch nuked again or still valid? |
| 14:14.13 | luf | merlin1991: what patch? |
| 14:14.19 | merlin1991 | bt name patch |
| 14:18.42 | luf | It's not fixing the root cause. So it works but isn't ideal. |
| 14:19.49 | merlin1991 | can we fix the root cause without touching the kernel? |
| 14:24.09 | luf | It has side effects right now because of change in kernel. |
| 14:24.45 | 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. |
| 14:26.16 | luf | merlin1991: I'll investigate it more so maybe I can be wrong right now. |
| 14:26.23 | luf | And for sure I need to leave now. |
| 14:40.51 | *** join/#maemo-ssu fredrinLap (~fn@cm-84.208.108.15.getinternet.no) |
| 15:14.37 | *** join/#maemo-ssu luf (~luf@ip-89-103-223-164.net.upcbroadband.cz) |
| 15:21.50 | luf | freemangordon: bluez-4.60 also waits till the kernel returns OCF_CHANGE_LOCAL_NAME and then read the name. |
| 15:31.11 | luf | But for sure there is a "hack" for off mode 4.60 :D |
| 15:31.11 | luf | static int adapter_setup: |
| 15:31.11 | luf | <PROTECTED> |
| 15:31.11 | luf | <PROTECTED> |
| 15:31.11 | luf | <PROTECTED> |
| 15:34.08 | *** join/#maemo-ssu fredrinLap (~fn@cm-84.208.108.15.getinternet.no) |
| 15:41.05 | *** join/#maemo-ssu andre__ (~andre@Maemo/community/bugmaster/andre) |
| 15:57.29 | kerio | freemangordon: are you the one that compiles busybox-power for -thumb? or is it iDont? |
| 15:58.43 | 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. |
| 15:59.26 | 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 |
| 16:00.23 | DocScrutinizer05 | so pretty please stay with kernl-x.x.88 API/ABI rather than elevating it to leete new kernel-x.y.99 |
| 16:01.05 | DocScrutinizer05 | rather backport $randomBTd rev9 patches to $randomBTd rev8 |
| 16:02.32 | DocScrutinizer05 | (obviously omitting those that cause the API change) |
| 16:03.03 | luf | DocScrutinizer05: :D |
| 16:03.18 | DocScrutinizer05 | or forward port the "borked" API details in $randomBTd rev9 from $randomBTd rev8 |
| 16:04.05 | luf | DocScrutinizer05: be sure we know your 2 cents ;) |
| 16:26.17 | *** join/#maemo-ssu toxaris (~toxaris@s83-180-246-172.cust.tele2.se) |
| 16:39.42 | kerio | i'm pretty sure fmg /ignored me :( |
| 16:40.26 | *** join/#maemo-ssu Pali (~pali@unaffiliated/pali) |
| 16:59.34 | luf | freemangordon: definitely the problem is in unread socket from bluetoothd side. |
| 17:00.41 | luf | It's a little bit better if I add g_main_context_iteration(NULL, FALSE); |
| 17:01.21 | luf | But it reads only one message per iteration and I have no idea right now how to read whole queue. |
| 17:04.15 | Pali | freemangordon, see code: https://meego.gitorious.org/~pali/meego-device-adaptation/pali-n900_libbme |
| 17:04.57 | Pali | I used socketpair instead pipe, because original libbme code returning pointer of socket |
| 17:05.22 | Pali | and application can read and write to socket |
| 17:05.31 | Pali | but from pipe only read (or write) |
| 17:12.59 | freemangordon | kerio: I was not here |
| 17:13.11 | kerio | excuses! |
| 17:13.13 | freemangordon | and yes, it is me to compile bb-power-thumb |
| 17:13.14 | kerio | :'( |
| 17:13.21 | kerio | i feel deeply hurt |
| 17:13.29 | kerio | only a busybox-power update could make me feel better |
| 17:13.29 | freemangordon | why? |
| 17:13.34 | freemangordon | aah :) |
| 17:13.42 | freemangordon | where is the source code? |
| 17:14.16 | freemangordon | Pali: hmm, iirc there was no need of socketpair, that is why i used pipes |
| 17:14.23 | freemangordon | though it should not matter |
| 17:15.12 | freemangordon | luf: but why only one message at a time? |
| 17:15.22 | freemangordon | I mean - what is the problem to read them all? |
| 17:15.27 | luf | Because of the callback function. |
| 17:15.35 | freemangordon | ? |
| 17:15.51 | freemangordon | callback gets called, you continue with the next |
| 17:16.16 | freemangordon | btw does it to select() on the socket? |
| 17:16.27 | freemangordon | s/it to/it do/ |
| 17:17.35 | freemangordon | luf: IIRC there was a way to read only the first "packet" from a socket and reschedule |
| 17:17.39 | 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). |
| 17:17.42 | freemangordon | lemme ask google |
| 17:18.20 | luf | I don't understand what are you thinking about. |
| 17:18.54 | luf | http://developer.gnome.org/glib/2.28/glib-IO-Channels.html#g-io-add-watch-full |
| 17:19.10 | luf | http://developer.gnome.org/glib/2.31/glib-The-Main-Event-Loop.html#g-main-context-iteration |
| 17:19.10 | freemangordon | thanks |
| 17:19.49 | luf | This detect there is something in the socket and call io_security_event (as defined with g_io_add_watch_full) |
| 17:20.33 | freemangordon | <PROTECTED> |
| 17:20.48 | freemangordon | i'll check it myself |
| 17:20.50 | luf | Should be. |
| 17:20.59 | luf | static gboolean io_security_event(GIOChannel *chan, GIOCondition cond, gpointer data) |
| 17:21.46 | luf | Hmmm maybe: g_main_context_pending () :) |
| 17:22.02 | freemangordon | ;) |
| 17:22.19 | freemangordon | the fuck, what's wrong with my PC, paste still does not work :( |
| 17:22.34 | freemangordon | i'll logoff/logon, bbl |
| 17:25.49 | *** join/#maemo-ssu freemangordon (~freemango@130-204-50-168.2074221835.ddns.cablebg.net) |
| 17:26.24 | luf | kerio: We're sorry but you're going to die :D |
| 17:28.19 | freemangordon | luf: g_main_context_pending won't do the job |
| 17:28.50 | luf | "while g_main_context_pending" do the job :) |
| 17:28.54 | luf | I hope |
| 17:29.04 | freemangordon | are you sure? |
| 17:29.31 | freemangordon | as IIRC you need ioctl(socket,FBIONREAD,&bytes_pending) |
| 17:29.32 | luf | Like a Fox. I want to believe :D |
| 17:29.52 | freemangordon | though I might forgotten how it works |
| 17:30.04 | freemangordon | well, lets hope then :D |
| 17:30.24 | luf | No. I'm not sure if it's ok to mix glib + direct access to the fd ... |
| 17:30.46 | freemangordon | me neither :) |
| 17:31.33 | freemangordon | DocScrutinizer05: now i remember that we found what the problem with wlan was. wifi switcher ;) |
| 17:31.37 | DocScrutinizer05 | hmß |
| 17:31.39 | DocScrutinizer05 | ?´ |
| 17:32.02 | DocScrutinizer05 | an appß |
| 17:32.08 | DocScrutinizer05 | DAMMIT? |
| 17:32.11 | DocScrutinizer05 | ???? |
| 17:32.17 | DocScrutinizer05 | ß?ß?ßßß???? |
| 17:32.20 | freemangordon | the guy had uninstalled wifi switcher (or whatever was the name) and no wlan after that |
| 17:32.22 | kerio | ßßßßßßßßßßßßßßßßßß |
| 17:32.38 | DocScrutinizer05 | an app?` |
| 17:32.41 | freemangordon | yes |
| 17:32.50 | DocScrutinizer05 | fair enough |
| 17:33.19 | freemangordon | "If I manually start icd2 as root as daemon (or with upstart) and disable & enable internet via wifi switcher. then it works." |
| 17:33.19 | DocScrutinizer05 | many thanks for sharing that historic bit of info ;-) |
| 17:33.33 | freemangordon | http://talk.maemo.org/showpost.php?p=1270059&postcount=776 |
| 17:33.50 | DocScrutinizer05 | ok, seems that's absolutely the story to explain that |
| 17:34.27 | freemangordon | yeah. thuough I cannot get it why this guy refuses to reflash |
| 17:34.41 | DocScrutinizer05 | I declare auto-disconnect deprectaed since years now, literally. All those hackers messing with ICD seem to have no real clue |
| 17:34.57 | freemangordon | ar was it auto-disconnect? |
| 17:35.03 | freemangordon | *or |
| 17:35.08 | *** join/#maemo-ssu fredrinLap (~fn@cm-84.208.108.15.getinternet.no) |
| 17:35.21 | freemangordon | not sure, but it was either of those |
| 17:35.22 | DocScrutinizer05 | some bullshit to tear down GPRS/WLAN after some time of no traffic |
| 17:35.59 | DocScrutinizer05 | wifi switcher might be same class of fsckdup BS |
| 17:36.04 | freemangordon | yeah, but I am not 100% sure which was the application to blame, auto-disconnect or wifi-switcher |
| 17:36.06 | freemangordon | yeah |
| 17:37.27 | DocScrutinizer05 | could those poor misguided lusers apt-get purge ICD2 ? |
| 17:37.34 | DocScrutinizer05 | the reinstall |
| 17:37.38 | DocScrutinizer05 | then |
| 17:37.47 | freemangordon | NFC |
| 17:39.13 | freemangordon | kerio: where is the source code of bb-power-thumb? |
| 17:39.20 | freemangordon | (new version) |
| 17:39.35 | kerio | freemangordon: dunno, hold on |
| 17:39.37 | freemangordon | tadzik: ping |
| 17:39.53 | freemangordon | kerio: ok. usually iDint send it via mail to me ;) |
| 17:39.57 | kerio | http://repository.maemo.org/extras-devel/pool/fremantle/free/source/b/busybox-power/busybox-power_1.20.2power2.tar.gz |
| 17:39.58 | freemangordon | *iDont |
| 17:40.04 | kerio | sounds legit |
| 17:40.08 | freemangordon | kerio: come on |
| 17:40.11 | kerio | what? |
| 17:40.26 | freemangordon | it needs -thumbN suffix and such |
| 17:40.43 | kerio | oh so you didn't /ignore me but you do ignore me :'( |
| 17:40.53 | kerio | points at the file extension |
| 17:41.08 | freemangordon | that is what iDont do before sending it to me, pester him, not me |
| 17:41.14 | *** join/#maemo-ssu _ade_ (~arno@52481E0B.cm-4-1a.dynamic.ziggo.nl) |
| 17:41.22 | freemangordon | _ade_: hi |
| 17:41.26 | _ade_ | hi |
| 17:41.40 | freemangordon | you could safely ignore these warnings |
| 17:41.46 | freemangordon | :) |
| 17:41.55 | _ade_ | okay, you get them too? |
| 17:42.03 | freemangordon | yes |
| 17:42.08 | freemangordon | the reason for them is: |
| 17:42.50 | freemangordon | linker thinks (for some reason) that object is hardfp, but as it is softfp assertion fails |
| 17:43.00 | freemangordon | but produced binary is ok |
| 17:43.15 | _ade_ | one other question: should non-thumb configs also be described for gcc 47? |
| 17:44.06 | freemangordon | you may try to pass -mfloat-abi=softfp for your test, to see if it changes the result |
| 17:44.15 | freemangordon | _ade_: rephrase please |
| 17:44.32 | freemangordon | configs? |
| 17:44.44 | _ade_ | well, thumb is not supported on non thumbs kernel, or? |
| 17:45.22 | luf | freemangordon: you're right. pending isn't what I need. |
| 17:46.17 | 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 |
| 17:46.43 | kerio | freemangordon: hm, you just need to add a new entry in the changelog and add the dep |
| 17:46.55 | _ade_ | okay, that can explain the (larger) sizes I see |
| 17:47.06 | freemangordon | _ade_:without -mthumb it produces regular ARM ELFs |
| 17:47.15 | freemangordon | kerio: no, it is maintainer job to do it |
| 17:47.18 | _ade_ | now I understand that |
| 17:47.22 | kerio | freemangordon: hm |
| 17:47.36 | _ade_ | freemangordon: yet another question: are compiler flags different? |
| 17:48.00 | kerio | freemangordon: really though, it's exactly the same thing you do for other packages |
| 17:48.18 | freemangordon | _ade_: you may want to explore the other goodies: -mfpu=neon -ftree-vectorize -fgraphite -lto |
| 17:48.51 | freemangordon | _ade_: some flags differ. and gcc 4.7.2 has much strict syntax etc. checking |
| 17:48.53 | kerio | hm, what's graphite? |
| 17:50.15 | _ade_ | freemangordon: thanks for explaining this. I could put some remarks about that in the wiki. Got to go work now, sorry |
| 17:50.28 | freemangordon | _ade_: thanks, np |
| 17:50.48 | freemangordon | kerio: http://gcc.gnu.org/wiki/Graphite |
| 17:51.23 | kerio | polyhedral optimization? |
| 17:51.23 | kerio | wtf |
| 17:51.57 | freemangordon | http://gcc.gnu.org/wiki/Graphite/Parallelization |
| 17:52.36 | freemangordon | luf: see now? why we don;t trust you :P |
| 17:52.51 | freemangordon | luf: one should read the socket until there is no more datat IIRC |
| 17:52.56 | luf | Why? I se no reason :D |
| 17:53.01 | luf | *see |
| 17:53.29 | freemangordon | now my paste works, lemme try to find something useful |
| 17:53.43 | freemangordon | luf: do you know where the socket is read? |
| 17:53.50 | luf | freemangordon: It's clear for me from the beginning. The question is how. I'll find the way ;) |
| 17:53.54 | kerio | luf: you fail at unix forever :'( |
| 17:54.06 | freemangordon | luf: ioctl(socket,...) |
| 17:54.11 | luf | kerio: really? :D |
| 17:54.14 | freemangordon | the one I wrote |
| 17:54.20 | kerio | reading a socket isn't guaranteed to return jack shit |
| 17:54.31 | luf | freemangordon: yes without B ;) |
| 17:54.33 | freemangordon | kerio: read what I wrote again |
| 17:55.12 | luf | freemangordon: it's read in the callback function |
| 17:55.35 | luf | But you don't want to put the loop there. For sure. |
| 17:55.37 | freemangordon | kerio: ioctl (socket,FIONREAD,&bytes_available) |
| 17:55.57 | luf | freemangordon: I'm compiling and I'll test. |
| 17:56.03 | freemangordon | luf: not there, return bytes avalable and check for 0 |
| 17:56.13 | luf | I hoped there is some function for it in glib ... |
| 17:56.25 | *** join/#maemo-ssu arcean_ (~arcean@aaet62.neoplus.adsl.tpnet.pl) |
| 17:56.28 | luf | freemangordon: I know ;) |
| 17:56.38 | freemangordon | and there MUST be some function in glib for calling a callback |
| 17:56.51 | freemangordon | (g-timer?) :P |
| 17:56.56 | luf | It's the iteration ... |
| 17:56.56 | freemangordon | g_timer |
| 17:57.03 | luf | Bleeee. |
| 17:57.22 | luf | forget about such shit :) |
| 17:58.47 | freemangordon | luf: g_main_context_invoke? |
| 17:59.06 | freemangordon | I bet that will do the job |
| 17:59.09 | luf | Nope. I already sent it |
| 17:59.18 | luf | g_main_context_iteration |
| 17:59.18 | freemangordon | sent what? |
| 17:59.25 | freemangordon | noo, g_main_context_invoke |
| 17:59.47 | freemangordon | check if you have pending bytes to read at the end of callback |
| 17:59.55 | freemangordon | and do g_main_context_invoke on callback |
| 18:00.06 | freemangordon | (if there are still bytes) |
| 18:00.26 | Pali | freemangordon, I will create new kp pre52 build |
| 18:00.29 | luf | Understand. |
| 18:00.54 | freemangordon | luf: or maybe g_main_context_invoke_full if you want to play with priorities |
| 18:00.59 | freemangordon | Pali: what has changed? |
| 18:01.00 | luf | FALSE |
| 18:01.11 | freemangordon | luf: what is FALS? |
| 18:01.21 | 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). |
| 18:01.28 | Pali | some changes in rx51_battery and bq2415x_charger drivers + enabled some iptables/ipv6 modules |
| 18:01.43 | freemangordon | Pali: great |
| 18:01.45 | Pali | and sigmask patch |
| 18:01.51 | freemangordon | aah, yes |
| 18:01.52 | freemangordon | :D |
| 18:02.08 | luf | The function usually returns TRUE ;) so invoke isn't such win. |
| 18:02.15 | freemangordon | hmm , i will send a mail to zeq tomorrow, it's been too long he is missing |
| 18:02.50 | freemangordon | luf: then return TRUE until there are no more bytes to read |
| 18:03.03 | Pali | btw, can merlin1991 import/promote packages in package interface? |
| 18:03.27 | freemangordon | I *think* he still cannot |
| 18:03.57 | merlin1991 | let me check |
| 18:04.16 | luf | freemangordon: Ee = no. It calls stop_hci_dev(index); prior to return FALSE. And it's for sure isn't what I want. |
| 18:05.09 | freemangordon | luf: sorry to ask again, which function is that? |
| 18:05.14 | luf | An in case EAGAIN it returns TRUE. |
| 18:05.18 | luf | io_security_event |
| 18:05.21 | freemangordon | ok |
| 18:05.43 | merlin1991 | maemo.org is slow :/ |
| 18:08.59 | DocScrutinizer05 | http://wiki.maemo.org/Community_SSU/known_broken_packages |
| 18:09.18 | luf | Shit I compiled wrong version :D |
| 18:09.36 | DocScrutinizer05 | add fapman there if you take joy in it |
| 18:11.58 | DocScrutinizer05 | don't ask me why I've put it under Community_SSU/ |
| 18:12.33 | luf | freemangordon: I thinking more about it and maybe reading the queue isn't a win as it can ends with stop_hci_dev ... |
| 18:12.55 | merlin1991 | Pali: I still can't |
| 18:12.59 | *** join/#maemo-ssu fredrinLap (~fn@cm-84.208.108.15.getinternet.no) |
| 18:13.04 | Pali | ok |
| 18:13.05 | freemangordon | luf: it won't stop if you check if there is anything to read prior to read() |
| 18:13.45 | luf | freemangordon: there should be also another event in queue ... |
| 18:14.58 | 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 |
| 18:15.58 | *** join/#maemo-ssu chainsawbike (~chainsawb@unaffiliated/chainsawbike) |
| 18:16.48 | freemangordon | or wrap io_security_event and do g_main_context_invoke on the wrapper |
| 18:16.54 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 18:17.43 | DocScrutinizer05 | ~broken |
| 18:17.43 | 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. |
| 18:18.06 | DocScrutinizer05 | ~broken-maemo |
| 18:18.37 | DocScrutinizer05 | ~broken-maemo is http://wiki.maemo.org/Community_SSU/known_broken_packages see this list for deprecated known borked packages |
| 18:18.37 | infobot | DocScrutinizer05: okay |
| 18:19.14 | kerio | DocScrutinizer05: wait, "not running preinst"? |
| 18:19.18 | kerio | what the fuck |
| 18:19.58 | luf | while (ioctl(dev->sk, FIONREAD, &bytes) == 0 && bytes > 0) - doesn't work. |
| 18:20.52 | freemangordon | not work as in? |
| 18:21.19 | freemangordon | also maybe you need g_io_channel_unix_get_fd(chan); |
| 18:21.26 | luf | Yes. It never goes into the loop. |
| 18:21.41 | freemangordon | what is dev->sk? |
| 18:22.39 | luf | I have no channel in the function. dev->sk is the fd to which is the hci_send_cmd sent. |
| 18:22.56 | luf | So it's the right fd. |
| 18:23.05 | freemangordon | are you sure there is only one fd for read and write? |
| 18:23.19 | luf | Maybe AF_BLUETOOTH doesn't implement such ioctl call. |
| 18:23.27 | freemangordon | hmm, could be |
| 18:25.15 | luf | <PROTECTED> |
| 18:25.55 | freemangordon | luf: according to google it is implemented |
| 18:26.01 | freemangordon | FIONREAD |
| 18:26.06 | freemangordon | what is errno? |
| 18:26.16 | luf | I didn't log it. |
| 18:26.25 | luf | * errno |
| 18:26.28 | freemangordon | yeah |
| 18:26.48 | freemangordon | the fuck, that should work :( |
| 18:27.45 | luf | Is it implemented in 2.6.28? I'm using KP51 (since yesterday). |
| 18:27.56 | DocScrutinizer05 | kerio: well, maybe running preinst, but to no effect since not showing the requesters in there |
| 18:28.07 | freemangordon | luf: it should be, lemme check the source |
| 18:28.22 | DocScrutinizer05 | kerio: it's a rough draft |
| 18:28.30 | DocScrutinizer05 | kerio: ...and a wiki anyway |
| 18:30.28 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 18:33.32 | DocScrutinizer05 | ~lart merlin for wasting percious time on #harmattan / N9-development |
| 18:33.32 | infobot | steals merlin's mojo for wasting percious time on #harmattan / N9-development |
| 18:34.00 | merlin1991 | ~lart DocScrutinizer05 for larting in general |
| 18:34.00 | infobot | lowers DocScrutinizer05's priority for larting in general |
| 18:34.03 | DocScrutinizer05 | look how smart she's with grammar |
| 18:35.06 | merlin1991 | DocScrutinizer05: so you have more reasons for you lart: https://metalab.at/wiki/Hack-A-N9 |
| 18:35.29 | DocScrutinizer05 | eew, I don't even dare to click that URL |
| 18:35.54 | freemangordon | luf: what about while(read()== HCI_MAX_EVENT_SIZE)? |
| 18:35.58 | DocScrutinizer05 | since there are no reasonable hacks that can be done to a N9 |
| 18:36.11 | freemangordon | I hope events are equal sizes |
| 18:37.09 | freemangordon | hmm, is it possible that we hist pselect() bug? |
| 18:37.13 | freemangordon | *hit |
| 18:37.34 | luf | freemangordon: are you even more crazy me? I can't read messages ... Or do I miss something? |
| 18:38.02 | freemangordon | luf: I am deffinitely more crazy than you :D |
| 18:38.20 | freemangordon | what do you want me to explain |
| 18:38.24 | freemangordon | ? |
| 18:38.33 | luf | how ioctl bullshit can depend on pselect? |
| 18:39.19 | freemangordon | luf: we are missing a callback call, correct? |
| 18:39.27 | freemangordon | which is not missed in 4.60 |
| 18:39.42 | luf | I don't think so. |
| 18:39.55 | luf | There is mode = "off" hack as I sent today ... |
| 18:40.04 | freemangordon | aaah, yes |
| 18:40.15 | freemangordon | luf: sory, I am stupid :) |
| 18:40.19 | freemangordon | *sorry |
| 18:40.49 | luf | No you're definitely not stupid. You work on several tasks at same time. I work only on one ;) |
| 18:40.52 | freemangordon | then why the hell we are losing our time when nokia is doing the same ugly hack? |
| 18:41.13 | freemangordon | that is why ^^^ |
| 18:41.25 | luf | I'm imbecil. I forgot to debug errno . I debug return value (-1) and bytes ... shit. |
| 18:41.27 | freemangordon | (I am stupid ) |
| 18:41.45 | luf | Because we're better. |
| 18:42.18 | 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 ;) |
| 18:42.19 | freemangordon | luf: scratch that, if it is workarounded in the same way in stock, do it the same way and forget |
| 18:42.24 | luf | We're real man :D |
| 18:42.32 | freemangordon | hehe |
| 18:42.48 | luf | But the changes are too huge to be sure. |
| 18:44.15 | luf | BTW I need to destroy the wall using my head ;) |
| 18:44.29 | freemangordon | what's wrong with the wall? |
| 18:44.52 | luf | Just it exists :D |
| 18:45.17 | freemangordon | aah, i understand now. go on then :D |
| 18:45.18 | luf | And not set BT name. You know ... |
| 18:46.21 | luf | And at last (not at least) someone said me: don't do it :D |
| 18:46.38 | *** join/#maemo-ssu fredrinLap (~fn@cm-84.208.108.15.getinternet.no) |
| 18:49.34 | freemangordon | DocScrutinizer05: http://talk.maemo.org/showpost.php?p=1270100&postcount=778 |
| 18:49.54 | freemangordon | LOL |
| 18:51.32 | DocScrutinizer05 | LOL indeed - 2somehow commented out" W*T*F! |
| 18:54.20 | freemangordon | luf: what now? |
| 18:54.37 | luf | errno 22 |
| 18:54.55 | freemangordon | eaccess? hmm, lemme check |
| 18:55.15 | luf | errno of 22 (Invalid Argument) |
| 18:55.21 | luf | Are you sure EACCESS? |
| 18:55.22 | freemangordon | aah |
| 18:55.24 | freemangordon | no |
| 18:55.32 | freemangordon | i was going to check |
| 18:55.53 | freemangordon | well, it seems it is not supported for AF_BLUETOOTH |
| 18:55.59 | luf | /usr/include/asm-generic/errno-base.h:#defineEACCES13/* Permission denied */ |
| 18:56.06 | freemangordon | ok, ok |
| 18:56.17 | luf | #defineEINVAL22/* Invalid argument */ |
| 18:56.21 | freemangordon | OK |
| 18:56.23 | freemangordon | :D |
| 18:56.31 | luf | :D |
| 18:56.46 | freemangordon | well, there are 2 options AIUI: |
| 18:56.54 | freemangordon | 1. use the same trick nokia did |
| 18:57.14 | luf | It's not nokia's trick. It's old bluez trick. |
| 18:57.17 | freemangordon | 2. read until there is no more data (if the socket is NONBLOCK) |
| 18:57.28 | freemangordon | I vote for 1 |
| 18:57.43 | luf | 2) how to check whan I can't read from it? |
| 18:58.09 | luf | That's still the same question from begining :D |
| 18:59.04 | freemangordon | you don't need to, read will return !=HCI_MAX_EVENT_SIZE |
| 18:59.18 | luf | Shit I see the possibility. I'm stupid bad guy (let me check ... yes I'm guy) :D |
| 18:59.47 | freemangordon | luf: though make a note that this is MAX |
| 18:59.54 | luf | I can test errno after the callback :) |
| 19:02.43 | DocScrutinizer05 | errwut? reading a queue after waiting for signal/callback? that'S a standard pattern, used all over the place |
| 19:02.58 | freemangordon | yes |
| 19:03.00 | freemangordon | ;) |
| 19:03.14 | freemangordon | the question is why it is not implemented in bluez |
| 19:03.56 | DocScrutinizer05 | since bluez obviously written by idiots, otherwise I don't see how using /etc/machinefoo as a semaphore file could come in |
| 19:05.11 | DocScrutinizer05 | *IF* you're using semaphore files, FFS do that in /var/run or similar location, *NOT* in /etc/ |
| 19:05.26 | freemangordon | luf: I think it won't work, frames have different sizes, without len member in the struct |
| 19:06.01 | freemangordon | so it will be very hard to process all the frames in the queue |
| 19:06.15 | luf | (08:59:54 PM) luf: I can test errno after the callback :) |
| 19:06.22 | freemangordon | so? |
| 19:06.36 | freemangordon | how does it help, elaborate please, I don;t get it |
| 19:06.49 | DocScrutinizer05 | freemangordon: WUT?????????? dafaq architects losz last synapse |
| 19:07.02 | freemangordon | DocScrutinizer05: seems so |
| 19:07.58 | luf | freemangordon: If there is nothing to read it should put EAGAIN into errno. |
| 19:08.28 | freemangordon | luf: but that is after first unsuccessful read AFAIK |
| 19:08.32 | luf | There is no function call after it so I think I can test it. |
| 19:08.40 | luf | Yes. It's what I want ;) |
| 19:09.57 | DocScrutinizer05 | freemangordon: not even implicit len, via msg identifier or sth? |
| 19:09.59 | freemangordon | DocScrutinizer05: see hci_send_req, they find next frame by adding the size depending on the current frame type |
| 19:10.10 | freemangordon | (plush header) |
| 19:10.14 | freemangordon | *plus |
| 19:10.18 | freemangordon | :( |
| 19:11.09 | freemangordon | DocScrutinizer05: aah, no |
| 19:11.21 | freemangordon | My mistake, hci_event_hdr has plen member |
| 19:11.33 | freemangordon | luf: ^^^ |
| 19:12.01 | DocScrutinizer05 | waves and heads out for a pretty well earned friday eve booze |
| 19:13.20 | freemangordon | luf: see what they do in see hci_send_req, the same should happen in io_security_event |
| 19:14.48 | freemangordon | luf: isn't hci_send_req a better place for setting the name? |
| 19:16.23 | luf | It's not called for such thing. The hci_send_cmd is the same code as in 4.60 ... |
| 19:16.41 | freemangordon | ok |
| 19:16.44 | luf | BTW check for EAGAIN isn't good option :D |
| 19:17.10 | luf | I have no running bluetoothd now :D |
| 19:17.17 | freemangordon | anyway, i'll try to fix the packaging. And I recommend you to use option 1 ;) |
| 19:18.00 | luf | :D |
| 19:18.15 | luf | Option 1 is still at web ;) |
| 19:22.10 | luf | Fuck it's not non-blocking :) So it blocks at the read :) |
| 19:22.34 | freemangordon | great :D |
| 19:22.52 | freemangordon | well, options were reduced :D |
| 19:22.59 | luf | No idea why they check EAGAIN :D |
| 19:23.22 | freemangordon | blocking call can be interrupted IIRC |
| 19:23.48 | freemangordon | don't ask me when and why |
| 19:24.03 | luf | Some interrupt or signal or something like that. |
| 19:24.26 | luf | Fuck how the glib checks it? |
| 19:24.35 | freemangordon | select |
| 19:35.36 | luf | freemangordon: true select or poll. |
| 19:35.54 | freemangordon | should be true select |
| 19:36.06 | freemangordon | not sure of course |
| 19:38.39 | luf | Ok, option 1 :D |
| 19:38.47 | freemangordon | :D |
| 19:39.06 | luf | As usual the wall is harder than my head :) |
| 19:45.03 | luf | So I'm leaving today ... bye |
| 19:45.11 | freemangordon | bye |
| 20:52.04 | kerio | DocScrutinizer05: http://talk.maemo.org/showpost.php?p=1270176&postcount=300 lololololo |
| 21:34.12 | kerio | freemangordon: FR: hardfp |
| 21:37.53 | tadzik | freemangordon: pong |
| 22:05.02 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 22:11.14 | *** join/#maemo-ssu MrPingu (~MrPingu@86.92.226.97) |
| 22:17.56 | DocScrutinizer05 | >>>I wonder, how many people are aware of reason, why cssu-extras is "no ETA" for half of a year, or more. It's quite simple - sexy idea in theory, but no one want to waste precious personal time (devs are quite overprojected, anyway), for establishing such thing. After all, if we have perfectly working things like bb-power - that could land in CSSU right ahead - why bother?<<< cubehead |
| 22:18.58 | DocScrutinizer05 | fsckng estel_ has no friggin clue 'why cssu-extras is "no ETA"' |
| 22:19.49 | DocScrutinizer05 | since meanwhile he's convinced not only me but also merlin1991 and chem|st are vice-satanas |
| 22:20.19 | DocScrutinizer05 | no, not santa's |
| 22:22.46 | Skry | oh |
| 22:23.13 | DocScrutinizer05 | and he the heck doesn't grok it how I can say "no, this won't happen", since he doesn't see my confidence in similar thinking of me and maintainers. He prefers to bitch "Doc, you LIAR! You're no maintainer of CSSU" DAFAQ does it even matter? |
| 22:25.37 | DocScrutinizer05 | I don't care if I'm a silly asshole that contributes random rant, a maintainer of CSSU, or Godfather of CSSU and nominator of maintainers. It doesn't matter. simple as that. What matters is condense and merit, and of course competence and sound arguments. Estel_ has none of those three |
| 22:25.46 | DocScrutinizer05 | consense* |
| 22:37.05 | kerio | what matters is codesense! |
| 22:37.39 | kerio | in xcode! |
| 22:37.42 | kerio | because java sucks! |
| 22:39.54 | Skry | so true |
| 22:50.29 | DocScrutinizer05 | how's that related to anything said before? |
| 22:51.38 | kerio | condense/consense/codesense |
| 22:54.29 | DocScrutinizer05 | ~dict condence |
| 22:54.41 | DocScrutinizer05 | ~dict consense |
| 22:54.54 | DocScrutinizer05 | ~dict codesense |
| 22:55.14 | DocScrutinizer05 | ~botsnack |
| 22:55.14 | infobot | DocScrutinizer05: thanks |
| 22:55.52 | DocScrutinizer05 | please keep in mind I'm no native speaker (like many others around here) |
| 22:56.13 | DocScrutinizer05 | (just like you, iirc) |