| tsdgeos | Mirv: https://code.launchpad.net/~timo-jyrinki/unity8/nochangerebuild/+merge/308027 ? | 09:41 |
|---|---|---|
| Mirv | tsdgeos: changed to WIP. related to a silo to try to fix the arm64 new kernel issues which didn't however give fully error free results. | 10:05 |
| tsdgeos | oki | 10:05 |
| Mirv | 5.7.1 would include all the patches, if that would work good then that'd give hope for 5.6.2 + patches or 5.6.3. | 10:05 |
| Mirv | if only I had time to work on Qt at some point, hopefully in January | 10:06 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| om26er | greyback: hello | 13:26 |
| om26er | greyback: you work on window management of unity8, right ? | 13:26 |
| om26er | It seems under Mir/Unity8 QML elements of apps report their globalRect relative to their window container and not relative to the display. This breaks autopilot for unmaximized windows. | 13:29 |
| bregma | om26er, the whole concept of "relative to the display" is nonsense, if autopilot depends it then autopilot is broken | 13:33 |
| Saviq | +1, autopilot should deliver events to a Mir surface with the relative geometry, only way to solve it | 13:34 |
| om26er | bregma: it kind of is broken, NOW ;) | 13:36 |
| om26er | Saviq: right, can we talk to unity to get geometry of a surface or do we need to go one level up... to Mir ? | 13:38 |
| Saviq | om26er, you don't want "geometry of the surface" | 13:40 |
| Saviq | om26er, you want to talk to Mir to send an event to the client directly, not through udev | 13:40 |
| om26er | Saviq: interesting, in that case, do I even need to worry which type of event(touch or click) the client should receive, or will Mir decide that on its own ? | 13:43 |
| Saviq | om26er, of course you do | 13:45 |
| Saviq | om26er, or rather, the test does, because behaviour might be different | 13:45 |
| om26er | Saviq: got any pointers on where I should look, to get started ? | 13:46 |
| Saviq | dandrader, do we have anywhere we could direct om26er about injecting input events to clients? ↑ | 13:48 |
| dandrader | Saviq, om26er I heard about some mir api that can be used to query the mirserver (unity8) on the whereabouts of client windows on screen. and with that info you could inject the corret events on udev | 13:49 |
| dandrader | om26er, better ask about it on #mir | 13:49 |
| Saviq | dandrader, that would depend on the shell implementation though | 13:49 |
| Saviq | I'm not sure that's the direction we want to go | 13:49 |
| dandrader | Saviq, as soon as unity8 uses miral, mir will have that info, so that mir API will work (so I was told) | 13:50 |
| dandrader | Saviq, I don't know whats the overall plan on that area | 13:50 |
| om26er | dandrader: curious to know, in a confined world wouldn't injecting input events through Mir be a challenge ? | 13:53 |
| dandrader | om26er, I thought autopilot was injecting them at udev level, so that's not affected by confinement. | 13:54 |
| dandrader | but autopilot would need uber powers on a full-snap system for that to work, naturally | 13:55 |
| om26er | dandrader: saviq suggests to stop injecting events through evdev and request Mir to do that on our behalf | 13:55 |
| dandrader | om26er, ah, ok | 13:56 |
| dandrader | still don't know much about snaps, so can't say any further | 13:57 |
| Saviq | sure it is affected by confinement, same as the other approach (we'd somehow need to authenticate autopilot to be able to do this) | 13:57 |
| greyback | sorry I was at lunch | 13:58 |
| om26er | dandrader: the current aim is to just enable autopilot under Mir desktop (without confinement). The main blocker that we discovered just recently is that content within an app container have their globalRect relative to their window container and not to the screen. So that causes issues for unmaximized windows | 13:59 |
| greyback | om26er: right, work needs to be done to enable that. As was said above, there is a mir api where a client can request the absolute position of its surface on screen. | 14:01 |
| greyback | but for technical reasons, we need to use the miral-based unity8 code, in order for that api to function correctly | 14:02 |
| om26er | greyback: ok, that brings me to the queston, can I use it today ? or should I wait for all window management to move to MirAL ? | 14:03 |
| greyback | om26er: easiest is to wait for window management in Miral. Otherwise we have to do work for the short term, that we'll throw away when we land the Miral stuff | 14:04 |
| om26er | greyback: hmm :/ I am kind of blocked as I was told to enable autopilot on Mir desktop before first Personal all-snap images. | 14:06 |
| greyback | om26er: I understand that, I wish I had better news. You could help us with the enablement with the miral-based code | 14:08 |
| greyback | om26er: there are a bunch of work items to be done for it, and we'd be happy for the help | 14:08 |
| om26er | greyback: heh, not sure if I have the skills to help there. Is there a place to track what's remaining to be done ? | 14:11 |
| greyback | om26er: not yet, but I can put that together | 14:13 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| dmj_s76 | Trevinho: Wanted to get some thoughts on improving hidpi support for Unity wrt 16.04, 16.10 and going forward. | 21:32 |
| Trevinho | dmj_s76: hey | 21:32 |
| Trevinho | dmj_s76: what you'd like to get. | 21:33 |
| dmj_s76 | I've done some basic testing of https://code.launchpad.net/~kaihengfeng/unity/set-hidpi-scale-factor and verified that it enables scaling on a hidpi laptop and does the right thing with an external monitor. | 21:33 |
| dmj_s76 | (Still need to test across the rest of our product lineup, but initially I'm quite happy with it. | 21:34 |
| dmj_s76 | What would be your thoughts about backporting these changes to the Unity in xenial and yakkety? | 21:36 |
| dmj_s76 | What kind of updates does Unity usually get as far as LTS point releases? | 21:39 |
| dmj_s76 | This is part of a project at System76 to improve 4K/HiDPI support on Ubuntu. | 21:40 |
| dmj_s76 | Trevinho: ^^ | 21:45 |
| Trevinho | dmj_s76: ah, that one was something that I wanted to check further, I've not the hw here.. i Can simulate it though, but Andrea was looking at it more closely. The idea is ok, however problably it would be better to have such code inside unity-settings-daemon | 21:47 |
| dmj_s76 | unity-settings-daemon seems to specifically defer to unity for some reason. | 21:48 |
| Trevinho | dmj_s76: however, if the change provides some fixes, we're now quite flexible on SRUing it to xenial (and yakkety, although this has less prio) after a staging period in zesty, so that we can verify it works | 21:48 |
| Trevinho | dmj_s76: yeah, well... Actually it was mostly an error of the past I think... I should have done that in usd instead that unity... However if it's still possible to move some logic there is fine. Otherwise I'm fine to continue in doing this in unity | 21:49 |
| Trevinho | (andyrock: on monday, read above ^^^^) | 21:49 |
| dmj_s76 | Either merging these changes or pulling in the changes from gnome-settings-daemon would be a fine solution from my end. | 21:51 |
| dmj_s76 | Either way, an SRU would be much appreciated. We're looking to offer HiDPI soon, which means xenial and yakkety need to work well. | 21:53 |
| dmj_s76 | I can provide testing on hidpi hardware, external displays, and a number of non-hidpi laptops to make sure there aren't any regressions. | 21:57 |
| dmj_s76 | Trevinho: ^^ | 21:57 |
| Trevinho | dmj_s76: good, we can work out a solution... If backporting something from gnome-settings-daemon is a solution, then we can follow also that path being tested code... But g-s-d has the problem that it only integer scaling, as all gnome. We have floating point scaling | 22:01 |
| Trevinho | or sort of... | 22:01 |
| Trevinho | so.... | 22:01 |
| Trevinho | dmj_s76: that's a good conversation to do, and I'm happy to help btw... Ping me and andyrock next week, and we'll sort out the best solution. | 22:02 |
| Trevinho | dmj_s76: you can also ask in #ubuntu-desktop so we can discuss also with others. | 22:02 |
| dmj_s76 | Sure, I'll bring it up monday. | 22:03 |
| andyrock | hey yeah we should understand why unity is a special case | 22:03 |
| dmj_s76 | Trevinho: andyrock: So installation and OEM firstboot should probably work correctly if the scaling code is in unity-settings-daemon | 23:29 |
| dmj_s76 | System76 can work around OEM firstboot in our mastering process, but just working there and fixing the regular install process for hidpi would be a plus. | 23:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!