**** BEGIN LOGGING AT Sat May 05 03:00:05 2018
May 05 08:59:14 <cos-> MonkeyofDoom: X is sw rendered, that causes it
May 05 10:33:30 <MonkeyofDoom> cos-: dang
May 05 10:33:42 <MonkeyofDoom> "hwcomposer" isn't hardware-accelerated?
May 05 10:33:56 <MonkeyofDoom> or is it e.g. xrender that have software backing rather than hw accel?
May 05 13:54:34 <greguu> MonkeyofDoom: the maxcpus=5 kernel parameter is just there to ensure the SoC does not overheat during early boot. Once booted, the kernel will use all cores available as required. (This seems to be a mediatek way of doing things..)
May 05 13:59:31 <greguu> MonkeyofDoom: Xorg is currently  (?) run via framebuffer afaik. The framebuffer does rely on rotation (90 degrees) via xrandr, this is dead slow. There is supposed to be some hwcomposer library that taps into the android driver via libhybris. TheKit maybe the best to explain how it works and what the current status is.
May 05 14:13:29 <NeKit> <MonkeyofDoom> glxgears gets 0.8-1 fps which is not quite stellar
May 05 14:13:41 <NeKit> glxgears uses OpenGL
May 05 14:13:56 <NeKit> try es2gears or something like this
May 05 14:21:46 <greguu> NeKit: if even in pure software OpenGL renderer, should it not return more than 1 fps ?
May 05 14:27:22 <NeKit> didn't read 0.8-1 fps part properly
May 05 14:27:25 <NeKit> it's really weird then
May 05 14:44:05 <greguu> NeKit: what woule be a sane average for es2gears in pure Xorg on x25 ?
May 05 14:47:46 <adam_b> greguu: I get 160 fps small and 130 fps full screen (es2gears-x25), 35 fps small and 2.5 fps full screen (glxgears-x25)
May 05 14:49:16 <greguu> adam_b: Thanks, the 2.5 fps on fs glxgears are close toe what MonkeyofDoom experienced then.
May 05 15:54:57 <MonkeyofDoom> ok I also see 170/130 fps for es2gears_x11
May 05 16:00:22 <MonkeyofDoom> it seems urxvt is *much* slower than other terminals (e.g. qterminal)
May 05 16:22:52 <greguu> MonkeyofDoom: it may use a transparent background, try "st
May 05 16:27:11 <MonkeyofDoom> yeah, turning off compositing in lxqt settings also helps speed of everything noticeably
May 05 16:28:29 <MonkeyofDoom> even afterward though qterminal still seems faster
May 05 16:28:44 <MonkeyofDoom> e.g. when printing new text at the bottom of an already-full screen
May 05 17:54:49 <NeKit> MonkeyofDoom, was compositing on by default?
May 05 18:01:55 <MonkeyofDoom> I think it may have been, but I don't recall; I've been changing settings all over
May 05 18:14:20 <NeKit> the situation with Xorg is that we theoretically have OpenGL ES acceleration (not desktop OpenGL), but mine Xorg DDX implementation isn't very optimal and relies on Glamor with GLES, which turned out to be slower than completely software Xorg, but provides nice way to integrate 3D (OpenGL ES2) rendering for apps
May 05 18:14:56 <NeKit> I should probably do some write up on wiki for basic idea and how exactly this is implemented so once more people get the device someone could help
May 05 18:15:29 <MonkeyofDoom> NeKit: that explains a lot, thank you
May 05 18:15:53 <MonkeyofDoom> what's the "ideal" backing for a DDX?
May 05 18:17:31 <NeKit> there are two options basically - either improve the current driver, or try to get Wayland, which is easier to due different architecture, but would require work for every compositor (kwin has hwcomposer backend with some bugs, but GNOME/mutter and others would need this implemented)
May 05 18:19:53 <NeKit> not sure what is "ideal", but if you upgrade xf86-video-hwcomposer from repo and add Option "AccelMethod" "None" in Device section of xorg.conf, you will get much faster desktop for "normal" operations, but GLES2 glue will fallback to slow copy
May 05 18:19:57 <MonkeyofDoom> what's the open-source GPU driver situation for Mali T800? panfrost aims to but I don't know its current status (and presumably it would require mainline kernels rather than the MTK 3.18 we have?)
May 05 18:20:04 <MonkeyofDoom> mm
May 05 18:20:20 <MonkeyofDoom> I don't really use 3D for anything, so that's probably worthwhile for now
May 05 18:20:30 <MonkeyofDoom> aims to support it*
May 05 18:20:53 <MonkeyofDoom> re: "improve the current driver", do we know what it's doing wrong?
May 05 18:20:57 <MonkeyofDoom> I guess I should look at the code
May 05 18:21:01 <NeKit> MonkeyofDoom, https://rosenzweig.io/blog/a-moving-mesa-midgard-cube.html
May 05 18:21:46 <MonkeyofDoom> yeah
May 05 18:24:22 <NeKit> currently in case of software mode, it gets Xorg to render to gralloc buffer, then uses OpenGL to blit it to screen rotated in same thread
May 05 18:25:23 <NeKit> I think using different thread to do the rendering could improve perfomance a bit, but it needs proper syncronization/copying of changed regions to avoid tearing
May 05 18:26:35 <MonkeyofDoom> what would be going on in parallel? software rendering of the next frame and the gpu blit of the current frame?
May 05 18:28:05 <NeKit> yes
May 05 18:28:18 <MonkeyofDoom> sounds reasonable
May 05 18:28:27 <NeKit> the bad thing is that Xorg doesn't even have concept of frames
May 05 18:28:32 <MonkeyofDoom> ugh, right
May 05 18:28:46 <MonkeyofDoom> I don't know what the programming interface for a DDX looks like
May 05 18:29:03 <MonkeyofDoom> time to google
May 05 18:30:46 <mifritscher> can't the gpu (or the lcd unit of it) rotate it?
May 05 18:33:33 <NeKit> if you want gpu to do it, then OpenGL (or, well, maybe Vulkan) is the way to go, as for second, no idea
May 05 18:38:10 <mifritscher> the lcd unit isn't directly in the gpu part I think, but a distinct unit
May 05 18:38:25 <mifritscher> its a pity that there is so little information of the SoC
May 05 18:38:27 <Beiriannydd> Oh My God I am in love
May 05 18:39:01 <MonkeyofDoom> welcome
May 05 18:39:21 <Beiriannydd> Just received mine yesterday and have been getting it tuned up.
May 05 18:39:31 <Beiriannydd> Thanks MonkeyofDoom
May 05 18:40:15 <Beiriannydd> I used to code for the Psion 3a and used to take notes on it
May 05 18:40:40 <Beiriannydd> My muscle memory has kicked in quickly!
May 05 18:41:06 <mifritscher> https://www.hotchips.org/wp-content/uploads/hc_archives/hc27/HC27.25-Tuesday-Epub/HC27.25.50-GPU-Epub/HC27.25.531-Mali-T880-Bratt-ARM-2015_08_23.pdf <- at least some technical information about the GPU, but I can't even find a complete datasheet about the Mediatek soc
May 05 18:41:07 <NeKit> mifritscher, if you know what you're looking for, maybe you could check mainlined DRM code for MT8173 Chromebooks?
May 05 18:41:35 <mifritscher> that could be an idea - if they have the same (or similiar) lcd unit
May 05 18:41:40 <NeKit> as for datasheets, there were some leaked ones at least
May 05 18:43:07 <NeKit> like http://www.smartpcba.com/uploadfiles/datasheet/MT6737_LTE_Smartphone_Application_Processor_Functional_Specification_V1.0.pdf
May 05 18:43:18 <Beiriannydd> I am sure that dguidi will share what he can once things calm down a little
May 05 18:44:00 <mifritscher> ah, thanks *reading*
May 05 18:45:55 <Beiriannydd> So, I rooted the device and installed the dualboot linux.  Has anyone been able to mount the dual boot linux under Android?
May 05 18:46:53 <NeKit> mkdir /data/local/mnt; mount /dev/block/mmclblk0p29 /data/local/mnt
May 05 18:46:56 <NeKit> something like this
May 05 18:50:34 <mifritscher> NeKit: do you know whether there is a display unit like  https://www.arm.com/products/graphics-and-multimedia/mali-display it in? the dp550 is a likely companion of the mali t880 (as descibed in the pdf). and this chip can indeed do hw-scaling and rotating - and I assume it is a lot easier to unterstand this piece than the t880^^
May 05 18:50:56 <mifritscher> (the chrome has a poverVR based gpu and thus likely a different display unit
May 05 18:52:31 <NeKit> hwcomposer does rely on something, but not sure which piece of hardware it is - it talks to https://github.com/dguidipc/gemini-android-kernel-3.18/tree/master/kernel-3.18/drivers/misc/mediatek/video/mt6797 in kernel
May 05 18:57:29 <mifritscher> ok, digging into it
May 05 19:02:17 <NeKit> in 6737 specs, there is MDP ROT_DMA, which may be of interest
May 05 19:03:06 <MonkeyofDoom> NeKit: oof, that code has bitmaps in it: https://i.imgur.com/HWztzu3.png https://github.com/dguidipc/gemini-android-kernel-3.18/blob/master/kernel-3.18/drivers/misc/mediatek/video/mt6797/dispsys/data_rgb888_64x64_golden.c
May 05 19:03:38 <NeKit> really wonder what is it for
May 05 19:03:47 <MonkeyofDoom> emergency something, I would assume
May 05 19:04:18 <mifritscher> hmm, there are signs of CONFIG_MTK_LCM_PHYSICAL_ROTATION_HW and rotate, but if I understand it correctly it is useful only for 180 degree rotation...
May 05 19:04:49 <NeKit> MonkeyofDoom, maybe they just used that as test bitmap for something?
May 05 19:06:15 <MonkeyofDoom> could be, I just downloaded the code so I can look at xrefs easier
May 05 19:06:52 <mifritscher> drivers/misc/mediatek/video/include/mtkfb.h has a interesting note: int xscale, yscale, mirror;	/* transformations. rotate is stored in fb_info->var */
May 05 19:06:59 <MonkeyofDoom> yeah, only referenced in a commented-out line of makefile
May 05 19:07:01 <MonkeyofDoom> weird
May 05 19:08:18 <greguu> maybe trumps golden shower pic. encoded in a mediatek kernel lol
May 05 19:08:48 <mifritscher> hmmhmm - Xorg  uses the fbdev driver, right?
May 05 19:09:25 <NeKit> no, customs hacks to render with Android's hwcomposer
May 05 19:09:40 <NeKit> fbdev works though
May 05 19:10:02 <greguu> NeKit: fbdev works also outside of X ?
May 05 19:10:52 <mifritscher> it could be a try to use the Rotate option of fbdev - https://linux.die.net/man/4/fbdev ...
May 05 19:10:53 <NeKit> theoretically yes
May 05 19:11:12 <NeKit> mifritscher, that option does software rotation
May 05 19:11:25 <NeKit> and it's pretty buggy in DEs for some reason
May 05 19:12:31 <mifritscher> :-( I hoped it tries to ask the fb
May 05 19:12:36 <mifritscher> interesting @buggy
May 05 19:21:56 <greguu> ah man, DirectFB did some awesome stuff back in tha dayz.. even with hardware accell, what we are facing now is just... no words
May 05 19:28:00 <mifritscher> hmmhmm, mktfb.c does indead read out the rotate flag in fb_var_screeninfo - but interestingly only to adapt x/y res...
May 05 19:28:27 <mifritscher> sadly it seems that mediatek did made its own lcd driver instead using the mali's one
May 05 19:29:57 <greguu> that is pure software rotation
May 05 19:31:44 <NeKit> mifritscher, that videox/dispsys code is relatively simular on PowerVR SoCs though, so DRM driver from Chromebook could be still useful to some extent
May 05 19:31:57 <NeKit> it also supports Banana Pi 2 with Mali-450
May 05 19:32:22 <NeKit> *similar on MediaTek SoCs with PowerVR, i. e. 6795
May 05 19:34:45 <MonkeyofDoom> does anyone know what "AEON_whatever"  refers to in the various device /proc entries?
May 05 19:35:18 <NeKit> aeon comes from their ODM name
May 05 19:37:03 <MonkeyofDoom> ah
May 05 19:37:54 <MonkeyofDoom> is the dguidipc/gemini-android-kernel-3.18 tree the same one used for the debian images?
May 05 19:38:24 <NeKit> mostly, mine repo is at https://github.com/NotKit/kernel-3.18-geminipda
May 05 19:40:42 <MonkeyofDoom> thanks
May 05 19:44:58 <greguu> mediatek clearly had no motivation to optimize their fb driver,what for, they had mali instead, maybe we should be looking at the fb instead of mali..
May 05 19:45:43 <greguu> more easy to get upstream and make is useable for end users
May 05 19:46:28 <NeKit> modern shells/DE don't perform well without 3D acceleration
May 05 19:46:58 <greguu> this is true, but i3wm and other would fly with just fb
May 05 19:48:29 <greguu> in the end its a keyboard only device
May 05 19:49:49 <mifritscher> hmm... http://www.smartpcba.com/uploadfiles/datasheet/MT6737_LTE_Smartphone_Application_Processor_Functional_Specification_V1.0.pdf . page 210 - there seems to be a "multimedia path" which can indeed rotate
May 05 19:51:08 <greguu> another, quite off topic, and unrelated, x11 rotation patch, using actuall hardware features https://github.com/mkatic/meta-zos/blob/master/recipes/xorg-xserver/xserver-kdrive-1.2.0/shadowfb_iwmmxt_rotate_copy.patch
May 05 19:53:31 <greguu> we would need something like this, just for mtkfb.c
May 05 19:53:53 <greguu> or xorg-fbev backend for that matter
May 05 19:54:47 <NeKit> greguu, from a quick look, not hardware features, but iWMMXt CPU extension
May 05 19:55:13 <greguu> which is hardware. no ?
May 05 19:55:43 <greguu> gcc makes use of it
May 05 19:55:51 <greguu> not a gpu
May 05 19:55:58 <greguu> but optimizations
May 05 19:57:05 <greguu> its asm code
May 05 19:57:35 <greguu> it makes quite a difference
May 05 19:57:40 <greguu> in performance
May 05 19:58:35 <greguu> compared to plain software rotation
May 05 19:59:04 <greguu> also, xrandr rotation was / is more slow than the routine used in DirectFB (even if outdated)
May 05 19:59:26 <greguu> on non accel hardware
May 05 19:59:32 <NeKit> asm code would need to be rewritten for arm64 though
May 05 19:59:34 <adam_b> I like the idea of the auto-rotate based on device orientation, so the p210 sounds good
May 05 19:59:36 <greguu> just from a software point of code
May 05 19:59:51 <NeKit> I think it doesn't have iwmmxt extension
May 05 19:59:58 <greguu> NeKit: this was just an example / idea
May 05 20:00:12 <greguu> iwmmxt is Intel only
May 05 20:02:00 <mifritscher> hmm, do we have access to a i2c line pair in the display's back or at the battery? i2c would be nice to connect a mt6605 - a nfc chip :-)
May 05 20:04:33 <greguu> well, to be fair, DirectFB did support PXA3xx board, (intel) ..
May 05 20:04:57 <greguu> so other ARM stuff.. not so much
May 05 20:05:42 <greguu> OMAP too, but meditek is a different league.
May 05 20:05:57 <mifritscher> btw, do we have a blockdiagram or even schematics of the gemini?
May 05 20:06:21 <NeKit> I don't think so, but that probably should be addressed to Planet
May 05 20:07:19 <mifritscher> yes
May 05 20:08:31 <greguu> https://notabug.org/cafe/chai seems to be still active.. maybe a good resource
May 05 20:08:38 <adam_b> someone should raise it on the forum, that way everyone can see the answer: developer.planetcom.co.uk
May 05 20:09:09 <NeKit> greguu, it's Panfrost driver which was linked before
May 05 20:09:38 <MonkeyofDoom> NeKit: do you take PRs to your kernel repo? I'm wondering what the right direction to take is for improving some of these drivers
May 05 20:09:39 <greguu> ah, ok I missed that
May 05 20:09:39 <NeKit> they have #panfrost channel here btw
May 05 20:10:09 <MonkeyofDoom> clean stuff up in the 3.18 repo, then eventually try to get enough drivers sane enough to port them to a mainline kernel and get things booting?
May 05 20:10:14 <greguu> lets ALL join that channel :)
May 05 20:10:16 <greguu> lol
May 05 20:10:45 <greguu> channel crashing
May 05 20:11:02 <greguu> respect to their effort
May 05 20:11:05 <greguu> hard work
May 05 20:11:30 <NeKit> MonkeyofDoom, probably it's better to get it under Gemian Github account so we have all things in one place
May 05 20:11:49 <MonkeyofDoom> sure
May 05 20:12:09 <MonkeyofDoom> is there any more insight into history of the code than "initial commit"?
May 05 20:12:52 <MonkeyofDoom> e.g. the organization of sysfs and proc entries is all nonstandard; is there some (Android?) userspace components that depend on that weird crap?
May 05 20:12:55 <adam_b> MonkeyofDoom: someone raised a bug on dguidipc's branch but last I looked there was no response
May 05 20:13:10 <NeKit> I got that source as tarball earlier
May 05 20:13:13 <MonkeyofDoom> mm
May 05 20:13:28 <NeKit> technically Planet has git history of whole Android tree, but it lacks complete kernel history as well
May 05 20:13:36 <MonkeyofDoom> sigh
May 05 20:13:44 <MonkeyofDoom> my temptation would be to just start trying to rework things to comply with upstream driver interfaces
May 05 20:14:20 <MonkeyofDoom> but it would be a shame if that means a long-term fork due to needing to maintain some of the weird MTK-branded ones in order for the Gemini android userspace to work
May 05 20:15:15 <adam_b> MonkeyofDoom: wouldn't have thought that was sensible till after we get the new kernel sources (with the new android)
May 05 20:15:30 <MonkeyofDoom> adam_b: ah, is that going to happen?
May 05 20:15:37 <MonkeyofDoom> ok then
May 05 20:15:40 <adam_b> If we keep the pressure up they might release more of a history with that branch
May 05 20:15:55 <MonkeyofDoom> who should I be poking to apply a bit of said pressure? ;)
May 05 20:15:58 <adam_b> Yea estimate is 'before the end of the year'
May 05 20:16:02 <MonkeyofDoom> oof.
May 05 20:16:22 <adam_b> well there is plenty of other things to fix first
May 05 20:16:25 <MonkeyofDoom> yeah
May 05 20:16:31 <NeKit> that history they have is only "Gemini-specific changes from normal MediaTek tree" though
May 05 20:16:51 <adam_b> NeKit: that is still useful
May 05 20:17:31 <Beiriannydd> mifritscher: I wonder if the rear camera slot could be repurposed for nfc?
May 05 20:18:15 <DaPol2> Beiriannydd: I2C hub (maybe SPI) and do manythings(tm)?
May 05 20:19:19 <Beiriannydd> I think it will be easier to see once people can see what hardware is attached to the camera module
May 05 20:20:47 <adam_b> did anyone order the camera module?, I've passed so far
May 05 20:20:58 <greguu> NeKit: btw: kexec added a new option "--no-checks" to allow booting images / kernels that require immediate control of the hardware without purgatory integrity checks
May 05 20:21:09 <Beiriannydd> I passed too, I didn't want the power bulge
May 05 20:21:38 <mifritscher> I purchased the camera module
May 05 20:21:46 <greguu> I did too
May 05 20:22:08 <greguu> means we have to wait longer..:)
May 05 20:22:34 * DaPol2 is wondering what the covers are made from - pondering shoving it into a laser engraver and would like not to have a magnesium alloy flare inside the engraver
May 05 20:23:30 <adam_b> DaPol2: weren't they laser engraving it anyway? (for the name on the spine)
May 05 20:23:55 <adam_b> though factories in china might not be so careful to their employees as you might like
May 05 20:24:00 <DaPol2> adam_b: No idea - looks pad printed to me
May 05 20:24:35 <adam_b> doesn't scratch off
May 05 20:24:37 <DaPol2> although tongue test says the text is below the surface level
May 05 20:24:47 <DaPol2> so, yeah - possibly laser engraved
May 05 20:25:06 <adam_b> sure I read it in an update
May 05 20:33:31 <MonkeyofDoom> adam_b: I have an order for one
May 05 20:34:11 <depscribe[m]> DaPol2 (IRC): did they at least get it right side up? wasn't on some of the prototypes.
May 05 20:34:36 <MonkeyofDoom> seems right-side-up here
May 05 20:35:18 <Beiriannydd> right way up here
May 05 20:35:42 <depscribe[m]> cool.
May 05 20:37:08 <MonkeyofDoom> is there any way to turn off the blue running light above caps-lock?
May 05 20:37:33 <MonkeyofDoom> it's not in /sys/class/leds
May 05 20:38:06 <Beiriannydd> ISTR someone saying it was a low battery warning, but I've only seen it on in Linux
May 05 20:38:41 <adam_b> MonkeyofDoom: the oesf forum has a post about that with an answer (leds)
May 05 20:38:49 <MonkeyofDoom> oh
May 05 20:39:52 <adam_b> both the internal one and the external ones are available, have been pondering a new linux service that can be dbus'd to request various states/transitions etc
May 05 20:41:23 <Beiriannydd> good idea adam_b
May 05 20:41:57 <Beiriannydd> df
May 05 20:48:35 <Beiriannydd> cd
May 05 20:48:38 <Beiriannydd> darn
May 05 20:49:12 <Beiriannydd> I am trying split screen mode... apologies, giving up on that for now
May 05 20:53:48 <MonkeyofDoom> adam_b: hmm, I can't seem to find the leds post?
May 05 20:54:11 <MonkeyofDoom> oh
May 05 20:54:16 <MonkeyofDoom> " Under Linux, the blue Caps Lock LED over the Tab/Caps Lock key is always turned regardless of the Caps Lock status. To disable it: echo "7 0 0 0 " > /proc/aw9120_operation ."
May 05 20:54:23 <MonkeyofDoom> https://www.oesf.org/forum/index.php?showtopic=34747&st=15&p=285197&#entry285197
May 05 20:56:55 <Beiriannydd> Fun. Caps lock is red in Android
May 05 21:05:26 <adam_b> the external led's are 3 colour, the internal one only two colour
May 05 21:05:54 <adam_b> so we can pick upto three levels of each colour for some level of mixing
May 05 21:06:52 <adam_b> any preferences for colours for the internal led for the caps lock/power plugged in/low power/any other state we want to indicate?
May 05 21:08:07 <adam_b> oh and I just updated the DebianTP with all the info from NeKit on how to get gprs to work
May 05 21:09:30 <adam_b> the DebianTP wiki page that is
May 05 21:15:51 <MonkeyofDoom> woww aw9120_led.c is so fucking poor
May 05 21:17:37 <adam_b> Yep, copy and paste job...?
May 05 21:18:08 <MonkeyofDoom> I'm not even sure a table is necessary; you might just be able to do arithmetic to get the values being assigned
May 05 21:18:51 <MonkeyofDoom> and instead of returning an erorr code from invalid writes to the procfs file they printk :(
May 05 21:26:45 <MonkeyofDoom> $ echo 2 | sudo tee /proc/aw9120_value
May 05 21:26:46 <MonkeyofDoom> neat
May 05 21:28:17 <MonkeyofDoom> this whole driver is a wreck
May 05 21:30:49 <NeKit> cleaning up the dmesg is going to be useful to avoid extra job by systemd-journald
May 05 21:30:56 <NeKit> Android just ignores kmsg
May 05 21:31:13 <MonkeyofDoom> mm
May 05 21:42:06 <adam_b> did you need the sudo tee? a simple > does the trick?
May 05 21:51:44 <MonkeyofDoom> oh it's 777 D:
May 05 21:52:14 <MonkeyofDoom> old habits &c.
May 05 21:56:35 <adam_b> so that value one lets you set special patterns, perhaps we should fix up the driver first to make it sensible before making a service for it?
May 05 21:57:01 <adam_b> (with animations etc)
May 05 21:59:20 <MonkeyofDoom> I think so
May 05 21:59:34 <MonkeyofDoom> http://www.awinic.com.cn/product_nei.php?id=77 the download link here is a reasonable datasheet
May 05 22:00:02 <MonkeyofDoom> this reminds me of the lp5523 controller on the n900, similarly programmable
May 05 22:00:19 <MonkeyofDoom> is there a standardized way to expose programmable LED controllers to Linux these days?
May 05 22:00:51 <MonkeyofDoom> the brightness/max_brightness/etc. entries in procfs don't really expose the hardware effectively
May 05 22:05:35 <MonkeyofDoom> https://lwn.net/Articles/687496/
May 05 22:09:56 <MonkeyofDoom> https://www.kernel.org/doc/Documentation/leds/leds-lp5562.txt might be a reasonable approach
May 05 22:39:39 <mifritscher> uh, pwm of only max. 244 Hz?
May 05 22:42:51 <mifritscher> but the ASP is nice
**** ENDING LOGGING AT Sun May 06 03:00:01 2018