[07:17] <zzarr> hello!
[07:20] <zzarr> I think that I should try to clone libhybris and rewrite it so that it can use a freon driver, that's the current approach I have
[07:29] <zzarr> duflu, do you think that using libhybris source would be a good start in order to communicate with freon?
[07:30] <duflu> zzarr: I don't know enough about freon... Hybris is only for Android systems and not ChromeOS so probably not
[07:35] <zzarr> I know that, but it should interface Mir so I though that if I rewrite the Android part so that it go against freon instead I should get the Mir part pretty much for free
[07:59] <anpok> zzarr: I believe you would have to integrate that: https://chromium.googlesource.com/chromium/src/gpu/+/3fe34d024f4726ad860771fab98b1e9b528bd3ab/
[08:18] <zzarr> thanks anpok
[11:00] <Saviq> hey guys, this is quite likely a Mir 0.20 - bug #1549226
[11:01] <Saviq> only happens on arale, I remember this being the case at some point in the past and you fixed it somehow :)
[11:01] <Saviq> bregma, camako, FYI ↑
[11:02] <davmor2> Saviq: are there meant to be 3 dots on it too? Under the location indicator
[11:06] <Saviq> davmor2, hmm? the three dots on the bottom? that's the indicator panel handle
[11:07] <davmor2> Saviq: when I say under the location indicator I mean they bleed through the indicator they are literally under it not below it
[11:08] <Saviq> davmor2, anything "bleeding through" is that bug above, unless I'm totally missing what you're asking :)
[11:10] <davmor2> Saviq: right okay that's what I was hoping for :)
[11:19] <alan_g> Saviq: it sounds like a wrong pixel format. And that sounds vaguely familiar from "overheard" discussions about arele
[11:20] <Saviq> yup
[11:41] <anpok> Saviq: sounds like the gl-fence change
[11:42] <anpok> or it behaves exactly like it..
[11:43] <anpok> we pulled it from 0.19 back then.. because it behaved like that on arale (while it fixes stuttering on n10) - but I thought we resolved the cause for that in the 0.20 version of the patch
[11:45] <Saviq> doesn't look like it
[11:49] <zzarr> If I bought a Dragonboard 410c would I be able to run Mir on it? (HDMI)
[11:51] <anpok> zzarr: alan_g has one
[11:51] <anpok> and runs mir with the freedreno driver iirc?
[11:51] <anpok> alan_g: so point release? and I can integrate the button bugfix?
[11:52] <zzarr> thanks anpok, I'll hear with alan_g
[12:01] <alan_g> anpok: sounds like it
[12:02] <alan_g> zzarr: I have it working, but not exactly a stable image (yet)
[12:04] <alan_g> So what I did was install the vivid based image from 96boards and then update from the xenial archive. Then Mir 0.20 works.
[12:05] <alan_g> (The essential part from xenial was the mesa stack - as the vivid image wasn't built with Mir support in mesa
[12:05] <alan_g> )
[12:06] <alan_g> zzarr: there's a snappy image in the works, but I'm not sure of the current status
[12:11] <alan_g> Here: https://insights.ubuntu.com/2016/02/24/canonical-to-offer-powerful-arm-64-bit-iot-developer-environment/
[12:17] <zzarr> thanks alan_g, but does that mean there will be a Mir driver for it in the future?
[12:20] <zzarr> ohh, now I see, I think I misread some, you're running Mir right now alan_g?
[12:21] <alan_g> Yes, it just needs the mesa driver built with mir support enabled. And that's in xenial
[12:21] <alan_g> So, with a xenial based image it works out of the box
[12:22] <alan_g> Mir-0.20 is now in xenial
[12:23] <anpok> zzarr: thats too boring for you!
[12:32] <zzarr> anpok, no it's not ;-)
[12:33] <bregma> zzarr, Canonical intends to make the DragonBoard 410c a reference platform
[12:33] <zzarr> that just means the Dragonboard 410c is on the buy list
[12:34] <zzarr> bregma, I know, but that is a future thing ;-)
[12:35] <zzarr> bregma, thanks for the reply in any way
[12:35] <anpok> oh kdub you are here... the transparent indicator problem is back on arale... Just like with the first time with the fence MP.. but maybe it is something different that has the same effect.
[12:35] <anpok> kdub: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1549179
[12:35] <kdub> anpok, ack, was just flashing that, will look
[12:44] <zzarr> alan_g, can the board be powered by USB?
[12:45] <alan_g> AFAIK no
[12:48] <kdub> anpok, from a quick look around, i think they changed the ro.product.device name
[12:48] <kdub> breaking our quirk detection
[12:49] <kdub> and giving another reason for https://trello.com/c/XzFGfwlE
[12:49] <anpok> ah yes
[12:50] <bregma> zzarr, the DragonBoard 410c requires an external 12 V power supply.
[12:52] <zzarr> okey, thanks bregma :-)
[12:58] <zzarr> alan_g, is the Dragonboard fast?
[13:00] <alan_g> Compared to? It's a passively cooled CPU on a chip, not a developer system.
[13:00] <alan_g> s/chip/card/
[13:03] <alan_g> Its about the same speed as a 14 year old laptop I have laying around. (But draws a lot less power.)
[13:07] <zzarr> alan_g|lunch, compared to the pi2?
[13:47] <zzarr> if I bought one Dragonboard and this display http://www.amazon.com/Eleduino-Raspberry-1024x600-Capacitive-TouchScreen/dp/B019K6CRVY/ref=sr_1_9?ie=UTF8&qid=1456321182&sr=8-9&keywords=hdmi+display and hooked them up, would the touch work?
[13:57] <alan_g> zzarr: @"compared to the pi2" I don't have one of those to compare. The specs are online though
[14:07] <alan_g> @"TouchScreen Display" it depends on what "Support...Ubuntu" means. Certainly not impossible, but I doubt anyone has tried it with libinput. anpok?
[14:13] <anpok> it is an USB touchscreen .. chances are goodt that it works out of the box.. only limitation .. we dont correlate touchscreen and diplay
[14:13] <anpok> *display
[14:14] <anpok> zzarr: ^ that means on your setup the output with your touchscreen should be your 'first' output..
[14:29] <zzarr> thanks anpok
[14:30] <zzarr> you see anpok I can make it trixy ;-)
[14:31] <anpok> yeah you could try attaching two of those..
[14:32] <zzarr> one HDMI and the other?
[14:36] <zzarr> should I use my imagination? USB to HDMI?
[14:37] <zzarr> but... I don't need 2 monitors to it.
[14:57] <bregma> just a note: the only difference between a touchscreen and a touchpad is where you put it on your desk:  there is really no correlation between a touchscreen and the display it's attached to other than the coordinate projection (usually) done in the display server
[14:57] <bregma> same goes for a (Wacom-style) tablet
[14:58] <bregma> from the kernel point of view they're all separate devices, some have multiple input axes, some have multiple touchpoints
[14:58] <bregma> some even have multiple buttons
[15:01] <bregma> a good design would leave all that pluggable and configurable, so add-on touchscreens and not-yet-imagined technologies like 3D gesture sensors and assistive technologies would "just work"
[15:01] <zzarr> thanks bregma, I know, a touch screen have absolute coordinates and a touch pad have relative
[15:02] <bregma> zzarr, nope, touchpads have absolute coordinates
[15:02] <bregma> some drivers will do cursor emulation, but that has nothing to do with what the device reports
[15:02] <anpok> bregma: well the device may appear simultaneously .. :)
[15:03] <anpok> may .. in zzarr case .. they wont .. since they are reached through separate cables..
[15:03] <bregma> internally, often the touchscreen is just a USB HID device
[15:03] <bregma> just because you don't see the cable doesn't mean it's not there
[15:04] <bregma> I mean it when I say touchscreens and touchpads are virtually identical devices and have nothing to do with the display they're associated with
[15:16] <zzarr> bregma, I know they are similar, and that a touchpad have absolute coordinates on device level, but I meant that they should be handled like a mouse
[15:18] <zzarr> bregma, I think you're wrong about internal devices often being USB HID's, I think that they are connected through some other bus like I2C
[15:19] <zzarr> I could be wrong but I don't see the reason why they should use USB
[15:25] <bregma> manufacturing cost:  vendors churn out plenty of HID devices and if they're all built to the Microsoft HID spec, they all just work
[15:25] <bregma> I have a large selection of touch input devices here, and every laptop I have that has touch sensors has them hanging off the USB
[15:26] <bregma> some of the mobile devices have bespoke drivers in the Android kernel, so it's harder for me to probe their real config without browsing Android kernel source
[15:28] <bregma> as for the display stack emulating relative coordinate for an absolute input device, sure, it can do that, but it's not because a touchpad and a touchscreen are different, it's because some configuration says "map absolute coordinates from the this device into relative coordinates and do pointer emulation" inside the display stack
[15:29] <bregma> or, really, the input stack associated with the display stack, so the cursor can be drawn on the screen
[15:30] <zzarr> bregma, thanks for the info
[16:10] <mzanetti> anpok, hey, so mir 0.20 landed, but the mouse is still broken in the emulator :/
[16:11] <anpok> was there a new emulator release?
[16:11] <mzanetti> does it need an emulator release?
[16:11] <anpok> or rather android release..
[16:11] <mzanetti> I thought a mir release would be the required thing
[16:11] <anpok> hm that fixes qml touch gestures in emulator
[16:12] <anpok> but the android patch will fix the emulated device being detected as an odd mouse..
[16:12] <mzanetti> anpok, so the weird thing is that with xenial it works fine, but it's broken with rc-proposed
[16:13] <anpok> hum it depends on when the emulator image was updated last time..
[16:14] <anpok> if is with the android input reading stuff.. the device will be detected as a touchscreen
[16:54] <alan_g> alf_: another try - https://code.launchpad.net/~alan-griffiths/unity-system-compositor/rework-DeadlockLP1491566/+merge/286698
[16:55]  * alan_g wishes he could reproduce failures that only happen during release
[19:49] <bschaefer> that would make the release cycle to easy :)