| lel | IMbackK opened a pull request: https://github.com/maemo-leste/osso-xterm/pull/3 (Don't use osso service activation) | 00:20 |
|---|---|---|
| lel | IMbackK synchronize a pull request: https://github.com/maemo-leste/osso-xterm/pull/3 (Don't use osso service activation) | 00:23 |
| lel | freemangordon closed a pull request: https://github.com/maemo-leste/osso-xterm/pull/3 (Don't use osso service activation) | 07:49 |
| _uvos_ | freemangordon: i dont think there is a bug | 08:11 |
| _uvos_ | its just impossible for dbus activation to work | 08:11 |
| _uvos_ | since there is just the one xterm dbus interface, but we have several seperate apllications running in xterms | 08:12 |
| _uvos_ | there is no way for the interface to work as desinged, as there is no way for it to know what application needs activation | 08:13 |
| _uvos_ | so short of having xterm crate a different service for eatch application i dont see how a solution is possible besides just not using dbus activation for xterm | 08:15 |
| freemangordon | uvos: and who and why tries to activate xterm? | 08:43 |
| _uvos_ | freemangordon: hildon | 08:44 |
| freemangordon | you mean - there are xterms, and you click on the launcher icon? | 08:44 |
| _uvos_ | so we have 1 application running in an xterm | 08:44 |
| freemangordon | gui application? | 08:44 |
| _uvos_ | this xterm was launched on behalf of this application | 08:44 |
| freemangordon | ok | 08:44 |
| _uvos_ | because its termnial=true | 08:45 |
| freemangordon | ok | 08:45 |
| _uvos_ | in .desktop | 08:45 |
| freemangordon | yeah, got it | 08:45 |
| _uvos_ | then the user wants a xterm | 08:45 |
| _uvos_ | right then the problem happens | 08:45 |
| freemangordon | lemme check how that works in fremantle | 08:45 |
| _uvos_ | in freemantle terminal=true is not supported | 08:46 |
| _uvos_ | we added that | 08:46 |
| freemangordon | does not matter | 08:46 |
| freemangordon | you still can start htop or mc | 08:46 |
| freemangordon | starting mc from the launcher starts mc in osso-xterm, trying to start osso-xterm after that brings mc on top | 08:48 |
| freemangordon | that's correct | 08:48 |
| freemangordon | if you want another terminal, you shall start it with "new" anyways | 08:49 |
| _uvos_ | i think this is bad | 08:49 |
| freemangordon | no | 08:49 |
| freemangordon | this is by design and sane behaviour imo | 08:49 |
| _uvos_ | its not sane at all imo | 08:49 |
| freemangordon | only one copy of xterm can be started from the launcher, no matter if something runs there or not | 08:50 |
| _uvos_ | if i click on xterm i want xterm not nmcpp or whatever | 08:50 |
| freemangordon | no, this does not work like that | 08:50 |
| freemangordon | new osso-xterm is launched from the menu | 08:50 |
| freemangordon | not from the launcher | 08:51 |
| freemangordon | new as in "new after the first" | 08:51 |
| _uvos_ | well yeah but osso-xterm is several different applications if its launched via .desktop termnial=true | 08:51 |
| freemangordon | also, see what ctrl-shift-x does | 08:52 |
| _uvos_ | the fact that this application is running in an xterm is just an implemnentation detail | 08:52 |
| _uvos_ | this is really broken if only one xterm is allowed | 08:52 |
| freemangordon | it opens new terminal even if there is already running one | 08:52 |
| freemangordon | I think you are getting this wrong | 08:52 |
| freemangordon | you *can* open new terminals | 08:53 |
| freemangordon | just not from the launcher | 08:53 |
| _uvos_ | since by your method whenerver one terminal=true app is running | 08:53 |
| _uvos_ | all .desktop files with terminal=true are broken | 08:53 |
| _uvos_ | its just broken behavior | 08:53 |
| freemangordon | what do you mean "broken"? | 08:53 |
| _uvos_ | they tont work | 08:53 |
| _uvos_ | you cant launch nmcpp while htop is running | 08:53 |
| _uvos_ | via its .desktop file | 08:53 |
| _uvos_ | the dekstop file is broken | 08:54 |
| freemangordon | well then, the issue is with "terminal=true" support, not with xterm | 08:54 |
| _uvos_ | untill all xterms are closed | 08:54 |
| _uvos_ | no | 08:54 |
| _uvos_ | because again | 08:54 |
| freemangordon | check how ctrl-shift-x opens new terminal | 08:54 |
| _uvos_ | yes i know | 08:54 |
| _uvos_ | it uses dbus | 08:54 |
| freemangordon | the same shall be done for "terminal=true" IIUC | 08:54 |
| freemangordon | so? | 08:55 |
| _uvos_ | the fact that htop runs in xterm is a im9plementation detail | 08:55 |
| _uvos_ | it shal not change the bavior of the xterm .desktop file either | 08:55 |
| _uvos_ | thats jus assinine | 08:55 |
| _uvos_ | *just | 08:55 |
| freemangordon | do I get it right that we discuss some imaginary distro with hildon and without osso-xterm? | 08:55 |
| _uvos_ | no | 08:56 |
| freemangordon | sorry, I don;t really understand the issue then | 08:56 |
| freemangordon | hildon-desktop shall call libhildonmime finctions to try dbus activation, if it fails, then it shall do what it does now (running osso-xterm directly, IIUC) | 08:57 |
| freemangordon | or rather osso-rpc | 08:57 |
| freemangordon | not libhildonmime | 08:57 |
| freemangordon | _uvos_: right now hildon just executes osso-xterm, right? | 08:58 |
| _uvos_ | except that dosent work for this case at all | 08:58 |
| freemangordon | WTYM? | 08:58 |
| freemangordon | what exactly does not work? | 08:58 |
| _uvos_ | as xterm can have serval personalities depening of it it was launched for the user | 08:59 |
| _uvos_ | or on behalf of some other application as an implementation detail | 08:59 |
| freemangordon | ok | 08:59 |
| freemangordon | ok, lemme try to explain my idea: | 08:59 |
| _uvos_ | anyhow this is useless i allready know your never going to reccognize the problem as its a design flaw in freemantle | 08:59 |
| _uvos_ | and we cant have those | 08:59 |
| freemangordon | _uvos_: do you get disconnected or you don;t want to discuss? | 09:00 |
| norly | _uvos_, freemangordon: i can confirm this xterm bug. | 15:31 |
| norly | launching htop from the hildon app meny first, then xterm from the app menu, doesn't open the second xterm window | 15:32 |
| norly | however the converse works: opening xterm first, then opening htop from the app menu results in two windows. | 15:32 |
| uvos | right the htop desktop file dosent use dbus activation | 15:52 |
| Wizzup | isn't that how it works on fremantle? | 16:02 |
| Wizzup | the only way to open another xterm is to use the menu | 16:03 |
| uvos | Wizzup: yes it is | 16:13 |
| uvos | Wizzup: the problem is this becomes broken when you launch .desktop files that implicitly open xterm | 16:13 |
| Wizzup | oh | 16:13 |
| uvos | ie launch htop or whatever | 16:13 |
| Wizzup | yeah that's a problem | 16:13 |
| uvos | then when you want to launch xterm.... | 16:14 |
| freemangordon | I think a proper fix is to not register xterm as osso-service when launched by h-d because of 'terminal=true' | 16:41 |
| freemangordon | maybe additional cmdline paramater or something | 16:42 |
| freemangordon | *parameter | 16:42 |
| Wizzup | right | 16:43 |
| freemangordon | not to say I think this is already implementd | 16:48 |
| freemangordon | https://github.com/maemo-leste/osso-xterm/blob/master/src/main.c#L49 | 16:48 |
| freemangordon | so, h-d shall start osso-xterm through dbus, by using "run_command" | 16:49 |
| freemangordon | this opens new terminal window and executes whatever needed, IIUC | 16:49 |
| uvos | this dosent help | 16:50 |
| freemangordon | why? | 16:50 |
| freemangordon | IIUC the particular issue is that you cannot start more than one applications with "terminal=true" | 16:50 |
| uvos | its still broken since the xterm desktop file will still focus a random application window instead of creating the "first" xterm window | 16:50 |
| uvos | no its not | 16:51 |
| uvos | this works fine | 16:51 |
| freemangordon | uvos: look at the code | 16:51 |
| uvos | since hildon dosent use dbus activation for desktop files without the x-osso-whatever key | 16:51 |
| freemangordon | well, we can teach it to do so for "terminal=true" | 16:51 |
| freemangordon | and this will be a proper fix - new window will be opened and it will get focus | 16:52 |
| uvos | then it would break it again | 16:52 |
| uvos | it works _now_ since it dosent use dbus activation | 16:52 |
| uvos | the problem comes if you launch the osso-xterm desktop file only | 16:52 |
| uvos | with the special key | 16:52 |
| uvos | since it dose use dbus activation | 16:52 |
| uvos | activating a random xterm launched by terminal=true | 16:52 |
| freemangordon | ok, thats another issue then | 16:53 |
| freemangordon | do you have example desktop file/application? | 16:53 |
| uvos | any deksktop file with terminal=true works fine here to repo | 16:54 |
| freemangordon | uvos: ok, to summarize: | 16:58 |
| freemangordon | 1. h-d support for terminal=true shall be changed to use dbus "run_command" method | 16:58 |
| freemangordon | 2. we can change osso-xterm to not focus (the first opened) terminal window but to create another window if needed, though I don't see why we shall do that given that you can always start "new" window from xterm menu | 16:58 |
| freemangordon | hmm, most-probably if we start osso-xterm for terminal=true in such a way that it does not register itself as dbus service will fix (2) too | 17:01 |
| freemangordon | norly: this is not a bug, this is by design | 17:03 |
| freemangordon | BTW the same happens on fremantle: if you start mc and then you start osso-xterm, mc is window is activated | 17:07 |
| freemangordon | *mc window is activated | 17:07 |
| freemangordon | but then again, you can always start new terminal from the menu | 17:08 |
| norly | freemangordon: this is totally unexpected and confusing | 17:11 |
| norly | but i see you already have ideas, so thanks a lot!! | 17:11 |
| freemangordon | norly: ever used fremantle? | 17:12 |
| norly | freemangordon: yes, but i haven't gotten around to set it up again to compare, sorry :( | 17:17 |
| norly | in any case, leste is evolving at an amazing pace, and even that already feels like being back home (like fremantle). so thank you so much. | 17:19 |
| freemangordon | Wizzup: uvos: what about adding another dbus method ('terminal'?) to osso-xterm that is used by h-d to start terminal=true applications and that sets a property ("no_focus_on_activation'?) of the particular window, so when dbus activation is requested, windows with this property to be excluded. if we have no available window to be activated, create a new one. | 17:24 |
| norly | freemangordon: that sounds great, actually! | 17:40 |
| norly | the no_focus_on_activation solution, i mean | 17:41 |
| tmlind | uvos: no idea what goes wrong there with the stock kernel.. but sure looks like the uart is not clocked when something is getting printed | 19:43 |
| uvos | tmlind: ok, its pretty wierd | 19:45 |
| uvos | tmlind: i just removed all printascii debug prints from kexec modules | 19:46 |
| uvos | it dosent help | 19:46 |
| uvos | 19:46 | |
| uvos | tmlind: btw kexecboot build root dosent build anymore with newer gcc | 19:47 |
| uvos | tmlind: theres a fix in upstream buildroot | 19:47 |
| uvos | its also to big and dosent fit anymore now :( | 19:48 |
| uvos | freemangordon: sure but that seams like a lot of effort for bahvior i think is bad ui anyhow | 19:52 |
| Wizzup | how about other non-terminal apps like contacts? | 19:54 |
| uvos | what about them? | 19:54 |
| uvos | sure contacts being a singleton make sense | 19:54 |
| uvos | same with sphone eg | 19:54 |
| uvos | the terminal? not so mutch | 19:55 |
| Wizzup | is there some xdg key for singleton? | 19:55 |
| uvos | there is a x-osso key | 19:55 |
| freemangordon | uvos: the rationale behind is that no new osso-xterm process is started, just a new window instead | 20:02 |
| uvos | so? | 20:03 |
| freemangordon | so you save on RAM | 20:03 |
| uvos | that dosent enforce the sigelton pattern in the ui wrt ram | 20:03 |
| freemangordon | Wizzup: every osso application is singleton one | 20:03 |
| uvos | really annyoing in other places to btw | 20:03 |
| uvos | like why cant i have to pdf viewers | 20:03 |
| uvos | two | 20:04 |
| buZz | dangit, maemo said 60% battery, i pull the usb cable , plop , shutdown | 20:04 |
| freemangordon | use your laptop | 20:04 |
| buZz | really think my install is kinda crooked again :P | 20:04 |
| Wizzup | maybe we can make it configurable | 20:04 |
| freemangordon | no, please, stop that | 20:04 |
| freemangordon | we have lots of gaps here and there | 20:04 |
| Wizzup | buZz: I think my device also please turns off a bit too quickly with older battery | 20:04 |
| buZz | i think the thresholds might be a bit too tight | 20:04 |
| buZz | or dno | 20:04 |
| uvos | buZz: mce turns it off it it goes below 3.45 volts | 20:04 |
| uvos | its quite conservative | 20:05 |
| uvos | since we cant boot if the voltage is to low | 20:05 |
| uvos | you can lower it a bit if you want | 20:05 |
| uvos | (at the expense of maybe causing to to be unbootable) | 20:05 |
| uvos | also the battery indicator lies if uncallibrated | 20:05 |
| freemangordon | uvos: I am under the impression that you are missing the point of what a mobile OS is | 20:06 |
| freemangordon | this is not server/desktop OS | 20:06 |
| uvos | i dont get why being on mobile should restict me in what windows i can open | 20:07 |
| uvos | but ok | 20:07 |
| freemangordon | because it is resource limited | 20:07 |
| uvos | but | 20:07 |
| uvos | its not | 20:07 |
| uvos | d4 can open hundres of xterms before its out of ram | 20:07 |
| freemangordon | because it opens new windows, not new processes | 20:07 |
| freemangordon | exactly because of the osso service acttivation | 20:07 |
| uvos | not really | 20:08 |
| freemangordon | yes, really | 20:08 |
| uvos | but thats not the point | 20:08 |
| freemangordon | what is tha RAM usage of a single osso-xterm process? | 20:08 |
| uvos | no idea but probubly not more than 4 meg | 20:08 |
| * freemangordon checks | 20:08 | |
| uvos | besides this is not the point | 20:08 |
| Wizzup | I think fmg says multiple pdf windows is fine, just preferrably not multiple processes | 20:08 |
| freemangordon | exactly | 20:09 |
| freemangordon | on amd64 VM, osso-xterm uses 23644k RES memory according to top | 20:09 |
| uvos | that.. tells us nothing | 20:10 |
| freemangordon | no, that tells us that it uses ~24MBs of RAM | 20:10 |
| freemangordon | "RES stands for the resident size, which is an accurate representation of how much actual physical memory a process is consuming" | 20:11 |
| uvos | no idea where you have that from | 20:11 |
| uvos | but it includes shared | 20:11 |
| uvos | so with what maemo launcher is doing... | 20:12 |
| uvos | also 64bit x86 != 32 bit arm | 20:12 |
| freemangordon | sure | 20:12 |
| uvos | number is mostly useless | 20:12 |
| sicelo | Without entering this discussion, may I mention that on Fremantle i have vim, htop and irssi ... all these have .desktops. i can open them without getting any of them to open in a random existing xterm window. | 20:12 |
| freemangordon | sicelo: yeah... but because they have "hildonized" .desktop files | 20:13 |
| freemangordon | we want to get rid of that | 20:13 |
| uvos | obviously replaceing all the .dekstop files in debian repos is out of scope | 20:13 |
| freemangordon | there is a standard way (terminal=true) | 20:13 |
| freemangordon | uvos: so, back to the matter - besides that it will require some effort to be implementd, do you see any other flaws in my proposal how to fix the issue? | 20:14 |
| uvos | no | 20:14 |
| freemangordon | ok | 20:14 |
| freemangordon | then please opens an issue and assign it to me | 20:15 |
| freemangordon | *open | 20:15 |
| buZz | didnt sliding closed after sliding open used to turn off screen | 20:15 |
| buZz | ? | 20:15 |
| uvos | yeah | 20:15 |
| uvos | i had to break this temprarly | 20:15 |
| uvos | mce dose this | 20:15 |
| freemangordon | buZz: auto-lock is broken too in -devel | 20:16 |
| freemangordon | but uvos said he'll fix it when he has some time | 20:16 |
| uvos | freemangordon: ill do it right after i get my device to boot again with sim | 20:16 |
| uvos | autorelock is harder | 20:16 |
| freemangordon | uvos: sure, I didn;t mean to sound offensive or something | 20:16 |
| uvos | freemangordon: no worrys | 20:17 |
| freemangordon | just explaining the situation | 20:17 |
| uvos | buZz: so mce relocks whever no input event was caused, except for events that are ignored | 20:17 |
| uvos | buZz: unfortionatly mce chooses events to ignore based on which device they come frome | 20:18 |
| uvos | buZz: unfortionaly on d4 the slider key and the volume buttons are on one deivce | 20:18 |
| uvos | buZz: you can have it ignore the volume buttons, or you can have it not ignore the slider key as an "input" for autorelock | 20:18 |
| uvos | you cant have both | 20:18 |
| uvos | atm | 20:18 |
| buZz | ah ok, cool , np | 20:19 |
| freemangordon | uvos: do you want me to look at this? | 20:21 |
| uvos | freemangordon: no its fine | 20:21 |
| freemangordon | ok | 20:22 |
| uvos | i just have to replace the filter system with soemthing that filters per key code instead of per device | 20:22 |
| uvos | its on my list | 20:22 |
| freemangordon | right | 20:22 |
| uvos | tmlind: not ever loading the uart module dosent help either :| | 21:12 |
| uvos | tmlind: so there is a bug in stock kernel uart subsystem that somehow triggers on kexec | 21:12 |
| uvos | tmlind: (with this sim) | 21:12 |
| uvos | really strange | 21:13 |
| uvos | tmlind: well im at a loss | 21:19 |
| uvos | tmlind: ill go with echo shutdown > /sys/class/radio/mdm6600/command; sleep 5 for now | 21:20 |
| uvos | that makes it boot reliably at least | 21:20 |
| uvos | Wizzup: tmlind: https://github.com/maemo-leste/clown-boot-kexec/tree/3.0.8-leste-simboot-tests <-- here will be the modules with working ainchent cross compile toolchain (x64) and build script if you have to build these hatefull things | 21:25 |
| uvos | in future | 21:25 |
| uvos | 21:27 | |
| Wizzup | honeycomb builds are now working on armhf, adding arm64 now | 22:05 |
| Wizzup | the speed beats the amd64 builds :) | 22:05 |
| uvos | Wizzup: great | 22:09 |
| norly | is there an easy way to have a mouse pointer when running the x86 build in a VM? | 22:22 |
| norly | as in, to have it *visible*? | 22:23 |
| norly | ah, got it. invoking qemu with -display gtk,show-cursor=on should do the trick :) | 22:32 |
| norly | next question then... F7/F8 are mapped to the volume keys. but when running the VM, is there a key to turn on the virtual screen again after it went to sleep? | 22:38 |
| uvos | F7/F8 are not mapped to the volume keys | 22:38 |
| uvos | just some applications react to f7/f8 the same as volume | 22:38 |
| uvos | anyhow | 22:38 |
| uvos | its by pressing the acpi power button | 22:39 |
| uvos | how thats done on your vm varies | 22:39 |
| uvos | freemangordon: new mce version should be fine wrt autolock | 23:10 |
| uvos | freemangordon: but dident test beacuse i use the newer cp applets that do not use the gconf if anyhow (so setting autolock works either way) | 23:10 |
| Wizzup | uvos: can you check the mce arm64 build | 23:18 |
| Wizzup | uvos: I am not sure if it's my changes or something in mce | 23:18 |
| uvos | none of the depends changed | 23:19 |
| uvos | so i dont see how it can be a change in mce | 23:19 |
| Wizzup | hmm | 23:19 |
| Wizzup | armhf worked fine though | 23:19 |
| Wizzup | and they are the same setup | 23:19 |
| Wizzup | maybe just retry? | 23:20 |
| uvos | its not finding any packges | 23:21 |
| uvos | looks like | 23:21 |
| Wizzup | ok | 23:21 |
| uvos | from leste repo | 23:21 |
| uvos | is it maybe missin in sources.list somehow? | 23:21 |
| uvos | sure i can retry that dosent cost anything | 23:21 |
| Wizzup | try again? | 23:22 |
| Wizzup | yeah | 23:22 |
| Wizzup | I just made a change | 23:22 |
| Wizzup | maybe not in time | 23:22 |
| Wizzup | let's see | 23:22 |
| uvos | still failing | 23:22 |
| Wizzup | oh I see.. | 23:22 |
| uvos | hmm? | 23:23 |
| Wizzup | I missed a config file | 23:25 |
| uvos | ready? | 23:25 |
| Wizzup | I started it | 23:25 |
| Wizzup | ty | 23:25 |
| uvos | ok | 23:25 |
| uvos | thanks | 23:25 |
| Wizzup | note it might still fail but that should be a predictable one | 23:26 |
| Wizzup | it will build the pbuilder env now | 23:26 |
| Wizzup | and then I will chroot and add the keys (one time thing) | 23:26 |
| Wizzup | yup | 23:26 |
| uvos | not sure what your doing there but im sure youl make it work :P | 23:27 |
| Wizzup | it should work this time | 23:28 |
| Wizzup | i've just been reverse engineering the bash history of root on the build pis that parazyd set up | 23:28 |
| uvos | lol | 23:28 |
| Wizzup | *shrug* | 23:28 |
| Wizzup | it works | 23:28 |
| uvos | maybe write it down this time | 23:28 |
| Wizzup | I have | 23:28 |
| uvos | good :) | 23:28 |
| Wizzup | both are set to 8GB ram and 6 cores | 23:29 |
| Wizzup | could increase it some but I don't want to fully hit the machine yet | 23:29 |
| uvos | ok | 23:29 |
| uvos | probubly the storage io speed is the biggest gain here tho | 23:30 |
| uvos | on the pis most of the time installing the packages took more time than the compile | 23:30 |
| Wizzup | yes | 23:30 |
| Wizzup | the speed is also 3x at least | 23:30 |
| Wizzup | going to sleep soon, but glad this is finally done | 23:37 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!