Wizzup | uvos: the meta pkg should fix that | 00:08 |
---|---|---|
uvos | Wizzup: yeah | 00:09 |
uvos | the meta package was uninstalled on all of my devices - again | 00:09 |
uvos | i never do this intentionally | 00:09 |
Wizzup | it can't be removed with apt upgrade for sure | 00:10 |
uvos | xt875 and xt894 boot fine with the packaged kernel | 00:15 |
uvos | xt860 dosent | 00:15 |
uvos | never gets anywhere (no serial out beyond stuff from mbm/stock kernel) | 00:16 |
Wizzup | you probably lack the ram thing | 00:45 |
Wizzup | (or not, I have to check) | 00:47 |
Wizzup | there is the &memory0 thing | 00:48 |
uvos | https://github.com/IMbackK/droid4-linux/commit/61e0af838435d02fb651671249c9bd4208384f8e | 00:49 |
uvos | https://github.com/IMbackK/droid4-linux/commits/droid3-516 | 00:49 |
Wizzup | hmm | 00:53 |
Wizzup | I will have to try tomorrow | 00:54 |
Wizzup | uvos: ok, the n900 patch makes the n900 boot and work | 01:25 |
Wizzup | ts, wifi, etc | 01:25 |
Wizzup | uvos__: I also get the oops on the n900 when pm is enabled and I reboo | 01:55 |
Wizzup | t | 01:55 |
Wizzup | uvos: I think the droid3 just boots for my on new kernel | 03:20 |
Wizzup | it has the usual freezes though | 03:20 |
uvos__ | devel time for the kernel then | 08:07 |
uvos__ | did we complain on linux-omap about the oops allready | 08:08 |
uvos__ | seams to happen on any omap then with the serial ports suspended | 08:08 |
tmlind | uvos__: please do, oops trace and how to reproduce easily would be great to debug this | 08:40 |
tmlind | i tried to reproduce reboot with serial ports idled but did not see any oopses in logs, i can see reboot occasionally fail sitting in some stuck state possibly in the bootloader | 08:42 |
Wizzup | uvos__: I also think I see better battery life | 10:33 |
Wizzup | uvos__: wait, ok, maybe I didn't properly test 5.18 on droid3 | 10:41 |
uvos__ | tmlind: ok will do! | 10:54 |
tmlind | uvos__: thanks! | 11:22 |
Wizzup | root@devuan-droid3:~# uname -a | 12:06 |
Wizzup | Linux devuan-droid3 5.18.9 #1 SMP PREEMPT Tue Jul 5 19:41:44 UTC 2022 armv7l GNU/Linux | 12:06 |
Wizzup | uvos__: works for me, but still loads of freezes/resets | 12:06 |
Wizzup | and also a trace from omapdrm | 12:07 |
uvos__ | ok | 12:10 |
Wizzup | also interesting: | 12:10 |
Wizzup | [ 298.897949] phy-mapphone-mdm6600 usb-phy@1: modem status: 4 awake | 12:10 |
Wizzup | [ 301.089935] phy-mapphone-mdm6600 usb-phy@1: modem status: 5 asleep | 12:10 |
Wizzup | [ 304.528991] phy-mapphone-mdm6600 usb-phy@1: modem status: 4 awake | 12:10 |
Wizzup | [ 306.729827] phy-mapphone-mdm6600 usb-phy@1: modem status: 5 asleep | 12:10 |
uvos__ | interesting | 12:10 |
uvos__ | modem dosent work on d3 no? | 12:10 |
uvos__ | anyhow thats good enough to push to devel or? | 12:11 |
uvos__ | maybe post the trace somewhere | 12:11 |
Wizzup | yeah I don't think it works | 12:11 |
uvos__ | and yeah my d3 is also super unstable | 12:11 |
uvos__ | on 5.15 | 12:11 |
uvos__ | never lives more than a couple of min | 12:11 |
Wizzup | https://paste.villavu.com/raw/Jy5yAiusGk6GR7PEBuGJGI5nj4LgAM4Evv5PbSfe/ | 12:12 |
Wizzup | it lives if you leave the screen off | 12:12 |
uvos__ | (active use, it idles ok ) | 12:12 |
Wizzup | yeah | 12:12 |
uvos__ | it also gets really hot | 12:12 |
uvos__ | like concerningly hot | 12:12 |
uvos__ | there where the sim tray is | 12:12 |
Wizzup | probably modem related | 12:13 |
Wizzup | so there's the pmic voltage warnings | 12:13 |
Wizzup | but you said they were harmless in the past | 12:13 |
uvos__ | those are no real problem | 12:13 |
uvos__ | this just means that mbm sets the voltages higher | 12:14 |
uvos__ | than on d4 | 12:14 |
Wizzup | here's this: | 12:14 |
Wizzup | [ 26.306915] asoc-audio-graph-card soundcard: ASoC: DAPM unknown pin Headphones | 12:14 |
uvos__ | that makese sense | 12:14 |
uvos__ | since its a older variant of the chip | 12:14 |
Wizzup | but also not a big deal supposedly | 12:14 |
uvos__ | and we can assume mbm sets the voltages ok | 12:14 |
Wizzup | this is modem related: | 12:14 |
Wizzup | [ 23.519958] phy-mapphone-mdm6600 usb-phy@1: Timed out powering up | 12:14 |
uvos__ | so we just need to up the acceptable range in the kenrel | 12:14 |
Wizzup | but I think the trace is here: | 12:15 |
Wizzup | [ 13.100494] ------------[ cut here ]------------ | 12:15 |
Wizzup | [ 13.101226] WARNING: CPU: 1 PID: 60 at drivers/gpu/drm/drm_bridge.c:1207 drm_bridge_hpd_enable+0x74/0x84 [drm] | 12:15 |
Wizzup | [ 13.116180] Hot plug detection already enabled | 12:15 |
Wizzup | there are also errors for emif_probe and for omap-aes | 12:15 |
Wizzup | I don't know how relevant those are | 12:15 |
Wizzup | it looks like the modem status awake/asleep comes from me turning the screen on/off | 12:16 |
uvos__ | we dont use emif | 12:16 |
uvos__ | unless tmlind added it recently | 12:16 |
Wizzup | probably the mce mapphone module | 12:16 |
uvos__ | im suprized it tires to probe | 12:16 |
Wizzup | in any case yeah the modem doesn't work yet afaik | 12:16 |
uvos__ | tmlind: comment? ^^ | 12:16 |
uvos__ | afaik adding the emif binigns to dts breaks on mapphones for unkown reasons | 12:17 |
uvos__ | so we just leave it alone to how mbm/stock kernel sets it up | 12:17 |
uvos__ | ah d4 also has the omapdrm trace | 12:18 |
Wizzup | oh yeah, there's also this: | 12:18 |
Wizzup | [ 9.597930] abe_cm:clk:0060:0: failed to enable | 12:18 |
uvos__ | the drm trace sounds not very serious but we should check if it happens on mainline | 12:18 |
Wizzup | right | 12:18 |
uvos__ | and report if so | 12:18 |
Wizzup | I'm not going to look very hard at the d3 atm now, but will/can later | 12:19 |
uvos__ | btw | 12:20 |
uvos__ | actually i imagined seeing the ants with the 5.18 | 12:20 |
uvos__ | now that im payin | 12:20 |
Wizzup | yeah, things look a bit different | 12:23 |
Wizzup | first time that a kernel upgrade yields free improvements huh ;) | 12:23 |
uvos__ | *attention it dosent seem to happen | 12:24 |
Wizzup | not sure what others think of this, but I think we have two gpio's in the back of most mapphones | 13:27 |
Wizzup | I think on the bionic we could use that for a keyboard, perhaps even use gpio-i2c or something | 13:28 |
Wizzup | i2c-gpio is what I mean* | 13:31 |
mglbg[m] | for the n900, what do i do if i want to turn the screen on when slide is open and off when slide closed? dont mind writing some bash, I just cant find where to look, older forum posts refer to unavailable /sys/devices/platform/slide... kind of locations. any ideas? | 14:17 |
mglbg[m] | i guess i could get some examples from the keyboard backlight, but the search was unfruitful for now | 14:18 |
buZz | mglbg[m]: yeah i want similar on d4 aswell :) | 14:45 |
sicelo_ | maybe something in mce config? at least my fremantle n900 works like that. i don't think scripts are the correct solution | 14:48 |
sicelo_ | if uvos__ doesn't have solution for you right away, submit a github issue. for script, you could unlock the device via dbus, and your script could be activated via evdev ... i think the sliders are visible there on both n900 and d4 | 14:52 |
mglbg[m] | how do i reach the mce config? meh this sounds a bit too far for me now sadly as i do not know what you are talking about .. looks like i need to be signing up for github.. | 14:54 |
sicelo_ | /etc/mce/mce.ini | 15:00 |
mglbg[m] | thamks, ill check it out | 15:08 |
sicelo_ | so you're both saying sliding keyboard up doesn't unlock the device in the default config? if so, it could be a regression, or our wiki is wrong and needs updating. it currently states "Additionally, if your device has sliding keyboard (like the Nokia_N900 and Motorola_Droid_4), then opening the keyboard will also unlock the device. Closing the keyboard will lock the device again, but only if you | 15:09 |
sicelo_ | have not interacted with the screen since the last slide up." | 15:10 |
sicelo_ | i might be wrong, but i think you should get the desired behavior by setting AutolockWhenSlideOpen to 0 in /etc/mce/mce.ini | 15:23 |
sicelo_ | ah .. yes i don't know mce anymore as it has undergone a lot of changes. | 15:25 |
sicelo_ | buZz: mglbg[m]: set "UnlockOnSlide" = 1 in /etc/mce/mce.ini. see https://github.com/maemo-leste/mce/blob/4ee0792ee09aa7d3638fc5129532cb0b84ddeddf/config/mce.ini#L131 | 15:25 |
uvos__ | this still works | 15:51 |
mglbg[m] | thanks guys, i tried the UnlockOnSlide in the .d/99- file, does not seem to work yet, trying to figure out if this is due to this setting or some other system changes | 15:52 |
uvos__ | mglbg[m]: that setting is int the lockGeneric section or? | 15:52 |
uvos__ | mglbg[m]: that only applies if you use lock generic | 15:52 |
uvos__ | mglbg[m]: so tklock allways unlocks on slide open | 15:53 |
uvos__ | mglbg[m]: if you want the device to allso allways lock on slide closed you can use lock generic for this | 15:53 |
uvos__ | if for some reason it dosent unlock when you slide it open with the default config that is a bug | 15:53 |
uvos__ | but i kinda doubt it since eveytone would have complained about that | 15:54 |
uvos__ | (and it still works here) | 15:54 |
mglbg[m] | yeah unlock no problem it is about turning off the sreen when sliding in | 16:04 |
buZz | yeah 'locking' when closing, thats something maemo 5 did on n900 quite well | 16:06 |
mglbg[m] | ok, ill check out the tklock | 16:06 |
buZz | but havent had similar on maemo 7 yet | 16:06 |
bencoh | buZz: "locking" when closing only happened if no event (keyboard/touchscreen) happened meanwhile | 16:10 |
bencoh | (i.e slide open, have a quick look at the screen without touching anything, slide close) | 16:10 |
buZz | indeed, but on maemo7 thats not happening | 16:10 |
bencoh | (on maemo5 I mean) | 16:10 |
buZz | maybe it always thinks something happened? | 16:10 |
Wizzup | uvos__: yeah I think we can move to -devel today | 16:14 |
bencoh | buZz: could be yeah | 16:16 |
uvos | lock on close is an issue with the button layout on d4 | 16:44 |
uvos | you cant have it lock on close if nothing was pressed and have the volume buttons work | 16:44 |
uvos | as the volume buttons and the lockslider are on the same input device on d4 | 16:44 |
uvos | so yes that dosent work and is a known issue | 16:44 |
uvos | allways locking on closed is something lock generic can do | 16:44 |
uvos | http://uvos.xyz/maserati/90-lock-on-slide.ini | 16:47 |
uvos | here you can put that into /etc/mce.ini.d if you want this behavior | 16:47 |
sicelo_ | < uvos> lock on close is an issue with the button layout on d4 <-- does it work at least for n900? | 16:48 |
uvos | no its disabled everywhere to avoid filtering away the volume buttons on d4 | 16:49 |
uvos | i need to rewrite mces intput pipeline to make it work again | 16:49 |
buZz | ahh | 17:17 |
rafael2k | hey, can anyone remind me again how to set a volume key to open the vkb? | 18:05 |
rafael2k | it is in transitions.ini if I remember | 18:05 |
Wizzup | damnit I have a pulse dial phone at home now | 18:08 |
Wizzup | but I can't send '#', so I can't dial into work meetings | 18:08 |
buZz | -pulse- phone :D | 18:09 |
buZz | lol, in .bg again Wizzup ? :D | 18:09 |
Wizzup | nope, amsteradm | 18:10 |
Wizzup | it has a nice sticker on it with feuerwehr and polizei numbers ;) | 18:11 |
buZz | :D | 18:15 |
rafael2k | you can just play the tones | 18:19 |
rafael2k | with an outsiđe speaker | 18:19 |
rafael2k | coupled with the phone | 18:19 |
Wizzup | not sure if the grandstream ata will turn the pulse dial into dtmf in the call too | 18:19 |
Wizzup | I'll have to check | 18:19 |
Wizzup | anyway offtopic :p | 18:20 |
Wizzup | but fun | 18:20 |
rafael2k | 941 Hz + 1477 Hz | 18:20 |
rafael2k | can use csound and maemo, and put the speaker close to the phone | 18:20 |
rafael2k | pulse is pulse, not DTMF | 18:21 |
rafael2k | just play the tones from any other device | 18:21 |
rafael2k | :P | 18:21 |
Wizzup | oh heh | 18:22 |
rafael2k | I used this in a "locked" (with key) phone in the past... you can just tap the hook to create de pulses - but not to create DTMF... ehehehhe | 18:23 |
Wizzup | so you're suggesting to generate the dtmf tones on my end? | 18:23 |
rafael2k | ATDT vs ATDP | 18:24 |
rafael2k | :P | 18:24 |
Wizzup | the numbers as dtmf tones? | 18:24 |
rafael2k | better not to mix I think | 18:24 |
rafael2k | you can try | 18:24 |
rafael2k | once the call is established via pulse, you can certainly switch to DTMF later | 18:24 |
rafael2k | which will be heard by a third party PABX | 18:25 |
Wizzup | right | 18:26 |
Wizzup | that's what I mean | 18:26 |
rafael2k | right, it will work, indeed | 18:26 |
rafael2k | you can get an acoustic coupler and feel like in the early 80's | 18:27 |
rafael2k | :P | 18:27 |
Wizzup | heh | 18:27 |
rafael2k | sorry, this is mid 70's | 18:28 |
rafael2k | you will also get for free a 1200 baud (software) modem if you wish to | 18:30 |
Wizzup | hehe | 18:43 |
buZz | so is 5.18.latest on hold? | 19:24 |
Wizzup | buZz: no | 19:26 |
Wizzup | it works in -experimental | 19:26 |
buZz | ooo | 19:26 |
Wizzup | I will push to -devel today | 19:26 |
buZz | sweeeet | 19:26 |
buZz | i'll port my bermbom mods :P | 19:26 |
mglbg[m] | <uvos> "http://uvos.xyz/maserati/90-lock..." <- thanks! this is one step further, the display goes off, but the led starts growing brighter white and the screen pops on again... | 19:28 |
uvos | mglbg[m]: heh it actually suffers from the same issue as autolock | 19:49 |
uvos | since the d4 now accepts the slider key as a valid event | 19:49 |
uvos | closing the slider also wakes it again | 19:49 |
uvos | so yeah | 19:49 |
uvos | thats also broken for the same reason the other lock on close is broken | 19:49 |
rafael2k | btw, a sample took with the gui app qcam (in libcamera-tools): https://www.abradig.org.br/maemo-crazyness/test.jpg | 20:47 |
rafael2k | debayering is really fucked up | 20:48 |
rafael2k | a guy developing for Mobian, Pavel, is also working on the PP (on Mobian) | 20:49 |
rafael2k | He also owns a Droid 4 and a N900 (and may be is even here, I dunno) | 20:50 |
Wizzup | machek? | 20:51 |
rafael2k | yes | 20:53 |
rafael2k | do you know him? | 20:53 |
Wizzup | yup | 20:53 |
Wizzup | he toyed a lot with maemo on the d4 and n900 | 20:53 |
Wizzup | but he's all over the place :) | 20:53 |
rafael2k | right... will not ask nothing about him not to jeopardize the work... ehehhehe | 20:54 |
rafael2k | he adds some funny signature is his emails... | 20:54 |
rafael2k | I better not comment | 20:55 |
Wizzup | something about horses? | 20:56 |
rafael2k | yes | 20:56 |
rafael2k | (metaphorically yes) | 20:56 |
rafael2k | bumped with him in libcamera mailing list | 20:57 |
sicelo_ | https://www.youtube.com/watch?v=fH6zuK2OOVU if you want to watch his talk on phone cameras and linux (before libcamera was a thing, iirc) | 20:59 |
Wizzup | uvos: in -devel | 20:59 |
Wizzup | sicelo_: maybe also check new kernel on d4 | 20:59 |
sicelo_ | rafael2k: ^ | 20:59 |
Wizzup | things feels different and better | 20:59 |
Wizzup | it's weird | 21:00 |
sicelo_ | Wizzup: i'll see if i can find time for it | 21:00 |
rafael2k | sicelo_: ow | 21:01 |
rafael2k | so no, I though you was joking about horses... he really showed a real horse in his presentation | 21:02 |
sicelo_ | hehe, of course. that's his pasttime. even on his facebook page, his livejournal account, and youtube channel ... horses :p | 21:02 |
rafael2k | no nooọ... | 21:03 |
rafael2k | these days things are more political | 21:05 |
rafael2k | shit, every time I read patches from mobian patchset I get scared | 21:25 |
rafael2k | stuff like: "Not sure how this works exactly. More tests are needed." | 21:25 |
rafael2k | "[PATCH 158/465] media: ov5640: [Experiment] Try to disable denoising/sharpening" | 21:26 |
rafael2k | I might try vanilla 5.19 to see what is really needed at some point | 21:26 |
Wizzup | :) | 21:27 |
rafael2k | echo 1 > /sys/class/leds/white:flash/brightness echo 0 > /sys/class/leds/white:flash/brightness | 21:36 |
rafael2k | flash is there | 21:36 |
rafael2k | : ) | 21:36 |
Wizzup | yeah, but it's not necessarily a standard interface | 21:36 |
Wizzup | we can also do flash on the d4 and n900, I think, but it's all custom | 21:36 |
rafael2k | hum... this is what is in mainline | 21:36 |
uvos | rafael2k: thats the wrong interface | 21:37 |
Wizzup | I imagined v4l had a property for it | 21:37 |
rafael2k | if (N900) elseif (d4) elseif (PP) | 21:37 |
rafael2k | : ) | 21:37 |
uvos | rafael2k: its supposed to be exposed via v4l | 21:37 |
rafael2k | hum | 21:37 |
uvos | rafael2k: but maybe implementing it v4l adds this led class device as a compatability feature | 21:37 |
uvos | rafael2k: the kernel dose that for lots of things | 21:37 |
sicelo_ | uvos: not necessarily. that's just how d4/n900 do it. but the pp implementation is correct as well | 21:37 |
uvos | the d4/n900 dont do it at all | 21:38 |
uvos | and no its not correct | 21:38 |
Wizzup | sicelo_: I think the point is that probably want something universal | 21:38 |
uvos | only v4l has the timeing information for a real flash | 21:38 |
uvos | the led class driver has no idea when to fire | 21:38 |
rafael2k | this is indeed in mainline, so I would not think it is wrong | 21:38 |
uvos | ( more important for a flash thats not a led that can blink for a long time but still) | 21:38 |
rafael2k | torch | 21:39 |
rafael2k | when power cuts kick in | 21:39 |
uvos | we where talking about using the flash as a flash | 21:40 |
uvos | ofc torch usage has not timeing requirements | 21:40 |
rafael2k | right, it should be exposed in V4L API too, agreed | 21:41 |
rafael2k | and indeed, the current for flash for picture is higher than in torch mode, afaik | 21:41 |
Wizzup | that would provide a universal interface | 21:41 |
rafael2k | https://leste.maemo.org/PinePhone#Enabling_Flash_Light_.2F_Torch | 21:42 |
rafael2k | adding things here before the wine takes them away ^ | 21:42 |
sicelo_ | https://elixir.bootlin.com/linux/latest/source/drivers/media/i2c/adp1653.c#L52 ... | 21:42 |
rafael2k | but sometimes simple interfaces are good too | 21:43 |
rafael2k | indeed sicelo | 21:44 |
rafael2k | settings are different, as it should be | 21:44 |
sicelo_ | the adp1653 is the driver on the N900 uvos | 21:44 |
rafael2k | cho 1 > /sys/class/leds/white\:flash/flash_strobe | 21:46 |
rafael2k | this is the flash_stobe in the in PP | 21:46 |
rafael2k | all also available tru V4L | 21:46 |
rafael2k | the LED framework overlap with V4L framework | 21:46 |
rafael2k | as far as I can see | 21:47 |
uvos | right as i said often a device is exposed automaticly in the other framework of you register it with one | 21:47 |
sicelo_ | rafael2k: really don't feel bad. the PP is doing the right thing, to the best of my knowledge. i have followed a little bit of the development around its flash :-) | 21:47 |
uvos | if the frameworks overlap in feature set | 21:47 |
uvos | also you can implement a v4l device in terms of a led class driver | 21:47 |
Wizzup | rafael2k: so for this to be a generic interface there needs to be a way to query what the purpose of LEDs is | 21:47 |
Wizzup | and sysfs doesn't really do that | 21:48 |
Wizzup | afaik | 21:48 |
uvos | the point is that just a led class driver | 21:48 |
uvos | is not sufficant | 21:48 |
Wizzup | this could just as well be the led on some other part | 21:48 |
uvos | because of timeing requirments | 21:48 |
rafael2k | linux is a mess, lets agree | 21:48 |
rafael2k | :P | 21:48 |
uvos | and also what Wizzup saying | 21:48 |
rafael2k | ls /sys/class/leds | 21:50 |
rafael2k | blue:indicator green:indicator red:indicator white:flash | 21:50 |
rafael2k | not thaaaaat bad | 21:50 |
Wizzup | yes it is | 21:51 |
Wizzup | but it doesn' | 21:51 |
Wizzup | t matter | 21:51 |
Wizzup | it's good that we know how to do it | 21:51 |
rafael2k | working... I would not get worried | 21:54 |
sicelo_ | you're doing awesome work | 21:55 |
rafael2k | : ) | 21:57 |
sicelo_ | n900 camera has been popping dmesg errors in recent kernels, and i hope to fix that. at least i found reloading the driver makes the errors go away. maybe you can help with getting pics out of it as you seem to know a lot about this stuff | 21:57 |
rafael2k | I thought Pavel made it work | 21:58 |
rafael2k | :P | 21:58 |
sicelo_ | yes he did. even took pics (matrix style - green) | 21:58 |
rafael2k | the made a leeeenghty presentation | 21:58 |
sicelo_ | but he doesn't have time for N900 in general anymore | 21:59 |
rafael2k | He mentioned in libcamera list it is in his top priority | 21:59 |
sicelo_ | hehe, when? and what? | 21:59 |
rafael2k | today | 21:59 |
sicelo_ | n900 camera? | 21:59 |
* Wizzup bbl | 22:00 | |
rafael2k | yeap | 22:00 |
rafael2k | and he says he uses Mobian on the PP, and Maemo in Droid 4 and N900 btw | 22:01 |
rafael2k | "I'm actually using Leste on Droid4" ... | 22:01 |
sicelo_ | rafael2k: i was completely confused earlier when we were talking about horses ... but now looking at the list i see what you meant :-D | 22:02 |
rafael2k | ehehehe | 22:02 |
rafael2k | that iconic image came to my mind... this is why I answered "yes" | 22:03 |
sicelo_ | one person i know would really like to see n900 camera working (and mapphones) is Laurent | 22:05 |
sicelo_ | *with libcamera, that is | 22:05 |
rafael2k | cool | 22:15 |
rafael2k | he understands _a_lot_ | 22:15 |
rafael2k | libcamera is the place to implement all these ISP pipeline setup madness | 22:18 |
sicelo_ | Wizzup: updating droid 4 kernel shortly. how's the stability, i.e. likelihood of unexpected reboots? | 23:08 |
sicelo_ | hmmm, died while updating. nice | 23:17 |
sicelo_ | ok it didn't. just screen went black and wouldn't react to powerkey for a while | 23:21 |
sicelo_ | Wizzup: does this come with your calls hack ootb? or something needed? i have a call to make tomorrow, so i could test with it perhaps | 23:24 |
uvos | no hacks | 23:27 |
uvos | very stable so far | 23:27 |
uvos | not a single reboot in 1week | 23:27 |
sicelo_ | alright | 23:46 |
Wizzup | sicelo_: no calls hacks | 23:50 |
Wizzup | like uvos said | 23:50 |
sicelo_ | alright. i'll use earphones then | 23:52 |
uvos | earphones? | 23:54 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!