[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 :)


[09:21] <bozhkov> hello
[09:21] <bozhkov> does anyone have an idea what is the deal with the security flaw in firefox 16 and what I as an ubuntu firefox user should do
[09:22] <bozhkov> i was automatically updated to 16.0 and i dont see a way to downgrade to 15.0.1 as propsed by mozilla security team
[10:44] <bootlfdhfrsa> I have serious difficulty this channel is a 'community' answer service at all.
[10:44] <bootlfdhfrsa> **that
[12:11] <jdstrand> if people ask a question, they should really stay in the channel for an answer
[12:11] <jdstrand> not having read all backscroll, 16.0.1 is undergoing QA
[12:11] <jdstrand> it should be published for all Ubuntu users in a few hours
[12:12] <jdstrand> if you want it sooner, you can download the packages directly from https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+packages
[17:31] <bootljhfdsds> http://goo.gl/yFOzQ
[17:32] <micahg> bootljhfdsds: if you would've stuck around another 30 minutes until someone was awake, you would've got your answer
[17:33] <micahg> if you're the same person that was here 6 hours ago
[17:38] <bootljhfdsds> micahg, My question was ...  What is the keystroke/s for using the back button on firefox       ? .. you had an answer ?
[17:39] <micahg> oh, sorry, wrong person (I'm apparently not awake yet)
[17:39] <bootljhfdsds> Ok I've found it http://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly
[17:39] <micahg> alt+left arrow
[17:39] <bootljhfdsds> So are you a member/user/or admin ?
[17:40] <micahg> all of the above?
[17:41] <bootljhfdsds> Cool. What do you think it would take to produce an Icecat version that could run-along-side firefox on the same system using ubuntu ?
[17:42] <micahg> not hard, just need to adjust the paths for install
[17:43] <bootljhfdsds> But can you use them at the same time, on different screens ? Not that I'm aware of...
[17:44] <bootljhfdsds> BRBack [cuppa required] .....
[17:48] <bootljhfdsds> he doesn't know..
[17:49] <micahg> that depends on whether or not they are using the same profile
[18:05] <bootljhfdsds> not sure what you mean by profile ? Dpo you mean in the programming or something that you actually log into ?
[18:15] <micahg> stuff in ~/.mozilla/firefox/
[19:46] <chrisccoulson> sigh, i don't think people realize it's a non-trivial amount of work for us to pull an update :/
[19:46] <micahg> right
[19:59] <bhearsum> chrisccoulson: tell me about it
[19:59] <chrisccoulson> hi bhearsum :)
[19:59] <bhearsum> hi :)
[20:01] <Unit193> You mean you can't just "update_firefox && package_firefox" ??


[00:52] <infinity> slangasek: When you play kernel SRU monkey, you should update tasks in the tracking bugs (and, in the case of ABI bumps, fix overrides when the packages all land in the wrong places).
[00:52] <infinity> slangasek: I've done both for you.
[01:03] <slangasek> infinity: right; I had meant to double-back and look at ABIs after the binaries landed but didn't get to it, so thanks
[01:04] <infinity> slangasek: *nod*... If nothing else, twiddling the tasks as soon as you accept is helpful, cause if you forget to do the overrides, the bot will yell at you later. ;)
[01:04] <infinity> slangasek: But it won't do its scan-and-be-grumpy dance until someone twiddles the copy task.
[01:04] <slangasek> infinity: where are the necessary bug-twiddling changes documented?
[01:05] <slangasek> pending-sru points at https://wiki.ubuntu.com/ArchiveAdministration#Copying_PPA_kernels_to_proposed, which doesn't seem to apply anymore
[01:05] <slangasek> when the kernel team sync, the *only* thing you get in the queue is an ack/nack button on the sync
[01:06] <infinity> That does kinda mention tracking bugs, but yeah, it doesn't seem to mention what to do about them. :P
[01:06] <infinity> And yes, syncs are very opaque, it's a known misfeature in LP.
[01:07] <infinity> Ideally, not only would they be more transparent, but they'd also let us override in the queue.
[01:07] <infinity> I do believe there are bugs open for both.
[01:07] <slangasek> ah right; I skimmed over that section of the instructions on account of it not having any useful links, and me not having a useful .changes file :)
[01:08] <infinity> That wiki bit should probably be updated to have a reference to http://status.qa.ubuntu.com/reports/kernel-bugs/reports/sru-report.html
[01:08] <infinity> Which nicely hilights tracking bugs (the magnifying glass), and such.
[01:09] <slangasek> thanks for volunteering to update it ;)
[01:13] <infinity> I'm allergic to wikis.
[01:14] <infinity> (opening the editor window...)
[01:17] <infinity> I can't help but think the kernel team had this all documented somewhere...
[01:18] <infinity> Oh, right, https://wiki.ubuntu.com/Kernel/kernel-sru-workflow
[01:19] <infinity> (As referenced in every tracking bug)
[01:19] <slangasek> right
[01:19] <slangasek> the tracking bug I couldn't find ;D
[01:19] <infinity> Check.
[01:25] <infinity> slangasek: There, have some "I'm not a tech writer" documentation.
[01:25] <infinity> I'm tempted to just tear the whole section out and replace it with a few lines.
[01:26] <infinity> "Reports here, if broken, fix overrides, don't do bad things, if do bad things, fix bad things."
[01:26]  * slangasek grins
[11:04] <seb128> ^ sorry about the nux screwups, GUADEC internet fail, I uploaded several times because it didn't seem to go through
[11:04] <seb128> rejected the extra ones, that should be sorted out
[11:06] <seb128> or ^ (bot lag)