| Wizzup | freemangordon: I can't figure out how to make a channel using ensureChannel* or createChannel* and actually pass any properties on the channel | 00:34 |
|---|---|---|
| Wizzup | telepathyprovider.cpp:136:135: error: use of deleted function ‘Tp::Client::ConnectionInterfaceAnonymityInterface::ConnectionInterfaceAnonymityInterface(Tp::Client::ConnectionInterfaceAnonymityInterface&&)’ | 00:58 |
| Wizzup | really | 00:58 |
| Wizzup | I don't know how anyone ever just groks the TP APIs | 00:58 |
| Wizzup | i'm just trying to set the anonymity bits using tp qt and it seems freaking impossible | 00:58 |
| Wizzup | they just offer this https://telepathy.freedesktop.org/doc/telepathy-qt/a09124.html | 00:59 |
| Wizzup | and a similar way for a channel | 00:59 |
| Wizzup | looking at this: https://telepathy.freedesktop.org/spec/Connection_Interface_Anonymity.html#Property:SupportedAnonymityModes | 01:32 |
| Wizzup | Note: Connections implementing this property SHOULD provide a corresponding parameter named org.freedesktop.Telepathy.Connection.Interface.Anonymity.AnonymityMandatory with the DBus_Property flag. Clients SHOULD update this property by calling UpdateParameters on the relevant Account rather than setting the property directly; change notification is via AccountPropertyChanged. | 01:32 |
| Wizzup | I can't get this to work with mdbus2 | 01:33 |
| Wizzup | it works fine on the connection interface, but not on the account | 01:34 |
| Wizzup | $ mdbus2 org.freedesktop.Telepathy.AccountManager /org/freedesktop/Telepathy/Account/ring/tel/account0 org.freedesktop.Telepathy.Account.UpdateParameters '{'org.freedesktop.Telepathy.Connection.Interface.Anonymity.AnonymityMandatory': <false>}' '<'Ignore'>' | 01:34 |
| Wizzup | [ERR]: GDBus.Error:org.freedesktop.Telepathy.Error.InvalidArgument: Protocol 'tel' does not have parameter 'org.freedesktop.Telepathy.Connection.Interface.Anonymity.AnonymityMandatory' | 01:34 |
| Wizzup | I think tp-ring just doesn't support it this way | 01:42 |
| Wizzup | interestingly enough, even with AnonymityMandatory=true and AnonimityModes=1 (req anon), the vm calls still show my number | 01:45 |
| Wizzup | on my vm | 01:45 |
| Wizzup | maybe my operator doesn't allow it? | 01:45 |
| uvos__ | Wizzup: or its broken on that modem/ofono driver | 01:50 |
| uvos__ | that would explain why no one compained about sphone hideing the number on pp | 01:51 |
| uvos__ | since sphone used to ask ofono to hide the number because it was swaped on d4 | 01:51 |
| Wizzup | maybe yeah | 01:52 |
| Wizzup | in any case I have a hacky patch for voicecall-manager | 01:52 |
| Wizzup | tested in my d4, to not hide caller id | 01:52 |
| Wizzup | s/in my/on my/ | 01:52 |
| uvos__ | its a bit wierd that setting it to 0 gives you a hidden number on d4 | 01:53 |
| Wizzup | 0 means nothing set, to do what modem or carrier says | 01:53 |
| uvos__ | this is supposed to mean operator preferance, on my d4 this results in it shown | 01:53 |
| Wizzup | 1 is request anon, 2 is do not request anon | 01:53 |
| uvos__ | hidden operator preferance is wierd imo | 01:53 |
| Wizzup | but I am talking about tp bits | 01:53 |
| Wizzup | https://telepathy.freedesktop.org/spec/Connection_Interface_Anonymity.html#Property:SupportedAnonymityModes | 01:53 |
| Wizzup | well, at least this is solved I guess | 01:56 |
| Wizzup | uvos__: btw, I made some hacky changes to sphone to allow any text in the dialer text field so that I could dial sip numbers and xmpp accounts | 01:58 |
| Wizzup | freemangordon: (re tracker) nothing in syslog | 01:59 |
| Wizzup | arno11: pls poke me tomorrow eve and we can make some more changes to the default images | 02:02 |
| Wizzup | 5.31 mW 53,1 ms/s 0,00 Process [PID 6799] /usr/libexec/tracker-extract | 02:05 |
| Wizzup | 4.72 mW 47,2 ms/s 0,00 Timer mix_interrupt_randomness | 02:05 |
| Wizzup | 2.15 mW 21,5 ms/s 0,00 Process [PID 4369] /usr/libexec/tracker-miner-fs | 02:05 |
| Wizzup | gah | 02:05 |
| Wizzup | freemangordon: the weird thing is that I didn't even add any music or really anything | 02:06 |
| sicelo | Wizzup: please have a look at https://github.com/maemo-leste-upstream-forks/ofono/pull/4 when you get time | 06:18 |
| freemangordon | Wizzup: so, tracker lost its db again and wouldn't recover it? | 07:29 |
| sicelo | Wizzup: i found the fix for ofono.RadioSettings interface issue i mentioned yesterday. will send it upstream shortly | 08:27 |
| arno11 | Wizzup: ok | 09:29 |
| Wizzup | freemangordon: looks like it | 09:46 |
| Wizzup | sicelo: great, will do | 09:46 |
| ac_laptop | hello people | 09:58 |
| ac_laptop | booted leste today after a full charge, it didn't have time to display the battery icon but it had time to play the "battery low" sound before shutting down | 09:59 |
| ac_laptop | I stand by my point : leste is not aware at boot that the battery is full, it needs "something" to be aware of it. I just don't know what that "something" is exactly | 10:00 |
| Wizzup | are you still swapping batteries? | 10:00 |
| ac_laptop | Now I'd like to know what program/daemon is responsible for the "if battery low then shutdown behavior", and how to disable it. | 10:01 |
| ac_laptop | Wizzup: I didn't swap batteries this time, I let the device plugged with the same battery | 10:01 |
| ac_laptop | Now I'd like to know what program/daemon is responsible for the "if battery low then shutdown behavior", and how to disable it. | 10:02 |
| ac_laptop | ↑↑↑ ↑↑↑ ↑↑↑ | 10:02 |
| Wizzup | linux kernel | 10:02 |
| Wizzup | at least on various devices, since it reads it directly from the battery gauging chip | 10:02 |
| Wizzup | which is probably still a little confused | 10:03 |
| Wizzup | but mce might act on low battery too and initiate shutdown | 10:03 |
| ac_laptop | If the linux kernel was responsible for it the device would go down after the linux kernel is loade, it would not wait for Xorg to be up | 10:04 |
| sicelo | Wizzup: yes, i would be happy for a new release of ofono. that patch helps a lot for my operator | 10:09 |
| ac_laptop | ok I've checked with an external charger, this time the battery is actually low | 10:10 |
| ac_laptop | there is something wrong with the charging | 10:10 |
| Wizzup | sicelo: ok\ | 10:11 |
| ac_laptop | can someone tell me the characteristics of the original nokia n900 charger ? the output values | 10:15 |
| sicelo | Nokia AC-10 | 10:16 |
| sicelo | Output: DC 5.0V / 1200 mA | 10:17 |
| Wizzup | ac_laptop: be mindful it might also be your usb port slowly getting loose | 10:17 |
| ac_laptop | sicelo: thank you | 10:18 |
| ac_laptop | I've got DC5V, 1.3A | 10:18 |
| sicelo | original charger? | 10:18 |
| Wizzup | sicelo: do I write 'add operator parsing' ? | 10:19 |
| sicelo | note N900 will draw high current from charger *only* if the charger has its D- and D+ pins shorted (that was the USB standard back then) | 10:19 |
| Wizzup | sicelo: or shall I just take your commit msg for the changelog | 10:19 |
| ac_laptop | sicelo: I thought it was, but I'm not sure now | 10:19 |
| Wizzup | will just do that | 10:20 |
| sicelo | Wizzup: you can, or maybe 'improve operator name parsing', since the commit adds a second way to get operator name | 10:20 |
| Wizzup | building now | 10:20 |
| ac_laptop | sicelo: you mean on the USB cable micro-USB end ? | 10:22 |
| sicelo | wherever :-) | 10:22 |
| sicelo | as long as by the time it connects to N900, that short exists | 10:22 |
| sicelo | anyway, charging on lower currents should still work | 10:23 |
| sicelo | can you describe properly/easily what you observe ... | 10:23 |
| ac_laptop | ok well on the original cable (which I stopped using because I couldn't flash u-boot with it), I see the full 5 pins so I guess it's not an original one | 10:26 |
| ac_laptop | the cable I've been using since then is a samsung cable from an other phone, it has 4 pins and D+ and D- are shorter indeed | 10:26 |
| ac_laptop | the AC/USB adapter even though it has nokia written on it might not be an original nokia one | 10:27 |
| sicelo | sorry if i was not clear. by 'short' ... i meant short-circuit | 10:28 |
| ac_laptop | sicelo: connected together ? | 10:30 |
| sicelo | anyway, the thing about short-circuit only affects how fast the battery will charge. as already mentioned, at 500mA max, e.g. when connected to a laptop's USB port, charging should still work normally | 10:30 |
| sicelo | connected together, yes | 10:30 |
| Wizzup | I have found n900 fremantle to be a bit more picky than n900 leste, there are a few chargers it just won't use | 10:30 |
| Wizzup | but this is easily solved by us | 10:30 |
| Wizzup | using another cable or charger | 10:30 |
| Wizzup | sicelo: should be built, ty for the pr | 10:30 |
| sicelo | thanks! | 10:31 |
| Wizzup | will be around later today again | 10:31 |
| ac_laptop | sicelo: ok well I guess I'll only charge on a laptop now, or use an external charger | 10:32 |
| sicelo | charge the battery from outside the N900? | 10:33 |
| ac_laptop | sicelo: yes, using something like https://www.ebay.com/itm/134669882725 | 10:34 |
| sicelo | ok. the fuel gauge won't like it, but it's not a problem. you'll always see "Needs Calibration" | 10:36 |
| ac_laptop | so we're now left with the possibility that the usb cable gets loose as Wizzup mentioned | 10:43 |
| ac_laptop | testing with an other battery while this one charges on the external charger, plugging the cable | 10:46 |
| ac_laptop | LED is green, wobbling the cable inside the microUSB | 10:47 |
| ac_laptop | no changes | 10:47 |
| sicelo | the thing is - none of us can know what's really the specific problem you have. we depend on the clarity of your explanation | 10:49 |
| ac_laptop | fremantle at least doesn't report any disconnection when I wobble the usb cable | 10:52 |
| sicelo | 10:59 < ac_laptop> booted leste today after a full charge, it didn't have time to display the battery icon but it had time to play the "battery low" sound before shutting down .... | 10:53 |
| sicelo | ^^^ so, you're saying the battery was really low, right? so leste did the right thing to shutdown here? | 10:54 |
| ac_laptop | sicelo: well, yes, the battery was actually low, when I put it on the external charger to check it showed less than 25% (probably near 0%) | 10:55 |
| ac_laptop | so I'm trying to understand why the n900 didn't charge its battery during the night while plugged | 10:56 |
| ac_laptop | maybe it's my AC adapter that is faulty, maybe I have a hardware issue on my n900 | 10:58 |
| sicelo | or things were simply not connected properly :-) | 10:58 |
| ac_laptop | but this time the problem does not depend on the OS, since the phone was off when it was plugged | 10:59 |
| sicelo | yes ... in fact we have mentioned a number of times that it's not Leste. even when the fuel gauge data is corrupt, voltage readout is correct, and that's what informs the shutdown decision in leste | 11:00 |
| sicelo | FYI, my main Leste device has completely broken USB port, so I always charge from outside the device ... but Leste always behaves normally | 11:01 |
| ac_laptop | sicelo: well I definitely had a couple occurrences when both fremantle and the external charger reported a full battery when lested reported a low one so there is also an issue there | 11:02 |
| ac_laptop | but I need to fix the hardware problem first | 11:03 |
| ac_laptop | I'll stop using the AC-USB adapter and see if I still have issues | 11:04 |
| sicelo | i'll provide a kernel patch in the hopefully near-future to deal with some edge cases when fuel gauge contains corrupted or inaccurate data | 11:05 |
| arno11 | sicelo: i checked again limits.conf stuff: rtprio option doesn't work without rt kernel apparently. | 12:02 |
| arno11 | if you can have a look when you have time | 12:02 |
| sicelo | oh that sucks | 12:02 |
| arno11 | yep | 12:02 |
| sicelo | i think in upcoming days things should be better on my end. done with the ofono work :-) | 12:03 |
| sicelo | so yeah, i hope to look at it soon | 12:03 |
| arno11 | ok and cool for ofono :) | 12:03 |
| sicelo | actually there's one more ofono thing i'd like to do, but not right away - the way it toggles the modem gpios is deprecated in the kernel. so we need to migrate to the new way | 12:05 |
| arno11 | ah | 12:06 |
| sicelo | arno11: CONFIG_GPIO_SYSFS in kernel is deprecated, and currently ofono uses it :-p | 12:11 |
| arno11 | that's sucks too | 12:53 |
| arno11 | *that | 12:54 |
| sicelo | kernel people actually said they'd remove that in 2020. we're lucky it's still there | 12:57 |
| arno11 | indeed... | 12:59 |
| uvos__ | "<sicelo> yes ... in fact we have mentioned a number of times that it's not Leste. even when the fuel gauge data is corrupt, voltage readout is correct, and that's what informs the shutdown decision in leste" | 13:28 |
| uvos__ | thats may not be copleatly true | 13:28 |
| uvos__ | mce shutsdown when the voltage is too low, or when upower reports that the battery is empty | 13:29 |
| uvos__ | im not sure how upower makes its determination exactly but possibly it may report the battery to be empty if the fule guage is very confused | 13:30 |
| sicelo | leste has a forked upower, which estimates capacity if fuel gauge is confused. the metric used for that is ... voltage | 13:31 |
| uvos__ | what is ofono doing directly writeing to gpios, that sounds like a bad idea in the firstplace | 13:32 |
| uvos__ | sicelo: ok | 13:32 |
| sicelo | https://github.com/maemo-leste-upstream-forks/upower/commit/13edc4622d19056c934bab196661145de8cbce01 | 13:33 |
| uvos__ | sicelo: so the fule guge thinking it knows whats going on but is wrong is not possible? | 13:33 |
| sicelo | writing to gpios from ofono is absolutely normal. even pinephone uses something similar, but because they use MM, which can't handle gpios, they needed an additional daemon, eg25-manager or some such | 13:34 |
| uvos__ | writeing gpios from usespace in liu of a kernel driver is generally fround uppon | 13:34 |
| sicelo | yes, but there are cases where it's needed, hence libgpiod, which i'll implement for the n900's modem in ofono | 13:35 |
| uvos__ | sure | 13:35 |
| uvos__ | but whats it doing exactly | 13:35 |
| uvos__ | why is it "needed" | 13:36 |
| sicelo | the modem is like a completely separate phone. you 'press' buttons to get it to a certain state, e.g. go online | 13:36 |
| uvos__ | that still very mutch sounds like a kernel kernel module should be doing this | 13:37 |
| uvos__ | like on d4 for instance | 13:37 |
| uvos__ | so with the fule guage: if somehow the fule guage thinks its callibrated, but is wrong a early shutdown should result due to upower reporting empty | 13:38 |
| sicelo | maybe ... although i would ask why the large community around pinephone didn't do it that way | 13:38 |
| uvos__ | sicelo: i mean thair kernel isent exatcly great | 13:39 |
| uvos__ | look at all the patches | 13:39 |
| sicelo | yes, but not all areas | 13:39 |
| sicelo | actually EG-25 is a generic modem, even Wizzup has it on his thinkpad, i think | 13:39 |
| uvos__ | he dose | 13:40 |
| sicelo | regarding fuel gauge, thankfully, it never thinks it's calibrated when it's not. | 13:40 |
| sicelo | plus, as i already mentioned, my N900 has such 'corrupted' fuel gauge because i always charge externally. the upower patches keep leste happy | 13:41 |
| sicelo | in pmos, where forking upower was not accepted, i carry a kernel patch | 13:41 |
| uvos__ | sicelo: maybe, im just wondering if there is some path to bug it out, via switching battiers or so | 13:41 |
| uvos__ | i dont know how the guage knows its not callibrated so cant comment if its somehow possible | 13:42 |
| uvos__ | was just mentioning that there is a second potential path to sutdown that dosent include voltage | 13:42 |
| sicelo | i always switch batteries :-) | 13:42 |
| sicelo | to rephrase ... yes upower will normally force shutdown when it thinks battery is empty. leste's upower fork invalidates that 2nd path though, by making its own estimate, based on voltage. so essentially, in leste there's just the voltage path | 13:45 |
| uvos__ | if the kernel knows not to report that the percentage/ capacity when its wrong in all cases, and cant be triced by any means | 13:48 |
| uvos__ | *tricked | 13:48 |
| uvos__ | i presume this is true | 13:48 |
| sicelo | rephrase? | 13:48 |
| uvos__ | if the kernel reports capactiy = 1 when its wrong, by some means, mce will shut down. if there is some way to trick it to think this even though the battery is full then a premature shutdown will result | 13:50 |
| uvos__ | this presumably is not possible, but im saying a potential bug in the hw or kernel could do this | 13:50 |
| sicelo | yes that's true. however, mce in leste does not ask kernel for capacity, right? | 13:51 |
| uvos__ | no but it shuts down on crictial level which iiuc is based on some theshold of capcaity | 13:52 |
| sicelo | who tells it the capacity? upower, right? | 13:53 |
| uvos__ | yes from upower, but its estimation code wont be used if the kernel reports capactiy = 1 so it will essentally path it though in this case | 13:54 |
| sicelo | ok, yes you're right. in the case of N900, kernel is guaranteed to report 0% for the case of corrupted data | 13:55 |
| uvos__ | yes but how dose the kernel know that the data is corrupted, if the stars aling poorly maybe just maybe it will get wrong valid data | 13:56 |
| uvos__ | i dont think this is likely | 13:56 |
| sicelo | the hw knows :-) | 13:56 |
| uvos__ | but im saying it may be possible | 13:56 |
| sicelo | and it tells kernel | 13:56 |
| sicelo | just to be clear, kernel won't set the 0% itself. the HW will, so kernel simply reports what it's told | 14:01 |
| sicelo | i had a long discussion with the upower people, where i was trying to get upower to factor in other parameters before deciding to power off (CAPACITY_LEVEL to be specific). unfortunately we didn't reach agreement, hence the kernel hack | 14:02 |
| sicelo | https://gitlab.com/postmarketOS/pmaports/-/blob/master/device/community/linux-postmarketos-omap/0012-bq27xxx_battery-add-voltage-based-capacity-estimatio.patch | 14:03 |
| uvos__ | sicelo: ok | 14:03 |
| uvos__ | sicelo: so not barring hw failure | 14:03 |
| sicelo | yeah, if hw has failed, then all hell can break loose :-) | 14:04 |
| uvos__ | yes | 14:04 |
| sicelo | actually what i want to do for N900 in leste is ... to stop using the minimal voltage set via mce.ini, and go back to using percentage as estimated by upower. for those with calibrated batteries, we'll magically detect that minimal voltage (3248mV) by using the appropriate HW flag (mapped to sysfs CAPACITY_LEVEL), and clamp reported capacity to something really low, e.g. 1%, which will cause | 14:20 |
| sicelo | upower/mce to shutdown | 14:20 |
| uvos__ | sicelo: the problem with that is that the charge estimation in upower is _terrible- | 14:21 |
| uvos__ | _ | 14:21 |
| uvos__ | so it will result in the device staying on too long | 14:22 |
| uvos__ | when uncallibrated | 14:22 |
| sicelo | it won't ... the hw-based CAPACITY_LEVEL will still be hit, and having clamped the capacity to 1%, things look 'normal' to mce/upower | 14:24 |
| uvos__ | un uncallibrated mode capacity isent reported at all | 14:24 |
| uvos__ | iiuc | 14:24 |
| sicelo | it reports 0% | 14:25 |
| uvos__ | right and that cause upower to estmate on voltage | 14:25 |
| uvos__ | wich its terrible at | 14:25 |
| uvos__ | so may be wrong up to 10% | 14:25 |
| uvos__ | this forces mce to act on voltage | 14:25 |
| sicelo | yup, | 14:26 |
| uvos__ | so we need to fix estmation, but thats a known problem | 14:27 |
| uvos__ | then we maybe can get rid of the voltage threshold | 14:27 |
| uvos__ | pending on how reliable our estmation is then | 14:27 |
| sicelo | regardless of how wrong upower's estimation will be, as long as the hw threshold hasn't been hit, you're sure you're ok. when it gets hit, kernel will know, independently of upower being correct or wrong :-) | 14:28 |
| uvos__ | sure but mce dosent know that | 14:28 |
| sicelo | at that point, we report 1%, and upower stops estimating | 14:28 |
| uvos__ | and has no way of knowing via upower afaik | 14:28 |
| sicelo | anyway, what i'm talking about is something i'm already using for a couple of months (under pmos) ... works fine with upstream upower. i just need to prepare one more kernel patch for an edge case, then i'm ready to submit it to leste | 14:30 |
| uvos__ | great | 14:30 |
| uvos__ | but we then have the problem | 14:31 |
| uvos__ | that we cant remove the estmation | 14:31 |
| uvos__ | because its needed on other devices | 14:31 |
| sicelo | yeah | 14:31 |
| uvos__ | so we need some way to enable it selectively | 14:31 |
| uvos__ | gets messy | 14:31 |
| sicelo | it's totally fine ... the estimation selects itself based on seeing a 0% condition. the rest of the time, all the devices aren't estimating, so we're good overall | 14:32 |
| sicelo | i actually wonder if we shouldn't upstream some of spinal's patches to upower | 14:33 |
| arno11 | sicelo: got voicecalls working at 100% i think. The key is to use high RR sched with pulseaudio. it works fine with chrt but can't find another way to do that. | 15:34 |
| arno11 | no other priority tweaks are needed anymore excepting cmt_pulse nice/renice | 15:35 |
| arno11 | no bug (but i'm using 16bpp and custom transitions) | 15:36 |
| arno11 | i'll try with a fresh install and see... | 15:37 |
| sicelo | even if the limits.conf isn't working, i think we can still use chrt/renice in a startup script of some sort, while keeping cmt_pulse running as user | 15:42 |
| arno11 | yes i think so | 15:42 |
| sicelo | Wizzup: or someone else, btw why do we have pulse running in system mode? not pushing for a change per se, but just to understand | 16:15 |
| uvos__ | gets messy | 16:53 |
| uvos__ | sicelo: we used to do this because we had no session wich was required | 16:55 |
| uvos__ | sicelo: it should be possible to run pa in session mode now | 16:55 |
| uvos__ | sicelo: this would improve performance because it would use shm then | 16:55 |
| uvos__ | sicelo: the estmation code needs to go long term | 16:55 |
| uvos__ | sicelo: its not generic at all, a nimh or li-fe battery would for instance be estimated totaly wrong | 16:56 |
| uvos__ | there is no way any of that can be upstreamed | 16:56 |
| uvos__ | so it gets messy since good estimation will be device dependant | 16:57 |
| uvos__ | never mind that it dosent work right even for the li-nmc cells we have now | 16:58 |
| freemangordon | oh, yes, pa should go to login session | 17:06 |
| freemangordon | we totally forgot that | 17:06 |
| sicelo | uvos__: yes the estimation stuff is not upstreamable. but there's, for example, a patch to prefer hw based time to full/empty | 17:15 |
| sicelo | cool @ pa | 17:16 |
| Wizzup | sorry, I will be back later | 17:16 |
| arno11 | cool for PA session mode, could help for N900 cpu usage | 17:55 |
| arno11 | freemangordon: i noticed that composition seems not disabled when an app is running in fullscreen (example: smplayer is laggy with no overclock and 360p video in fullscreen. Ctl+Shift+N solves the issue...same with pcsx) | 18:41 |
| arno11 | it's particulary visible in 16bpp | 18:43 |
| uvos__ | arno11: yes this is a know issue | 20:49 |
| uvos__ | arno11: hildon-desktop is silly, it needs a special atom to tell it to go into non-composed mode | 20:50 |
| uvos__ | arno11: all other wms just unredirect when fullscreen | 20:50 |
| arno11 | ah ok, really good to know | 20:52 |
| uvos__ | https://github.com/maemo-leste/hildon-desktop/blob/6324ad83ad5c28f3114595756a52835a76cb6310/src/mb/hd-comp-mgr.c#L1726 | 20:57 |
| uvos__ | we should just remove this and base it on it being fullscreen only imo | 20:57 |
| uvos__ | the only downside is a tiny delay on switch or when a popup notifcation comes up | 20:57 |
| uvos__ | but it benefits everything essentally | 20:58 |
| uvos__ | fullscreen applications are most likely to be heavy and or of a nature that the user dosent constanly switch away | 20:58 |
| uvos__ | this is why all desktop wms disable in this state | 20:58 |
| arno11 | indeed makes sense | 21:01 |
| * Wizzup catching up | 23:08 | |
| Wizzup | sounds fine to me @ pa in user | 23:17 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!