bschaeferRAOF, hey, soo digging through libinput today, looks like minimal work to add a function to get an FD from a libinput_device01:57
bschaeferthough the other way around will be a bit trickier01:57
* bschaefer assumes passing in the libinput struct01:57
bschaeferand fd01:57
bschaeferand going through all the event devices01:57
bschaeferand checking if the FD == FD01:57
bschaeferRAOF, cant imagine that taking to much time either01:58
bschaeferRAOF, which from there... i should be digging around the libinput-platform in mir to figure out where we can collect said FDs01:58
RAOFAt worst we'd need to pass in the path and the fd; libinput does need a way to probe the udev properties for the device, and I don't think it'd be able to do that given just an fd.01:59
bschaeferper surface, and figure out where to send that info on the callback (if its setup for the surface)?01:59
bschaeferRAOF, o i see, the only function i saw that did that was a add_device01:59
bschaeferfrom a path01:59
bschaeferwhich im not sure if that what we *really* want01:59
RAOFHm, why not?01:59
bschaeferRAOF, well wouldnt that add a device that is already added?02:00
RAOFWhy would it be already added?02:00
bschaeferhmm well since we would be passing the FD?02:00
bschaeferto unity802:00
bschaeferwe would need that FD to get a libinput_device struct02:00
* bschaefer assumes at that point we already have added the device02:01
bschaeferRAOF, cause the over issue is unity8 getting a libinput_device struct from a list of FDs we send it02:01
RAOFYeah, Unity8 has its own libinput context.02:01
bschaeferooo i see02:01
bschaeferso yeah... we'll need to pass and FD + path?02:02
bschaeferwith this function?02:02
bschaeferso it can open it, it self?02:02
RAOFYeah. We might be able to get away with just the fd, but I'm not sure.02:02
bschaeferyeah thats something that should be checked02:02
RAOFWell, we don't want it to open it itself (indeed, we want it to be *impossible* for it to open it itself)02:02
* bschaefer is new to udev/evdev/libinput02:02
bschaeferRAOF, we just want it to have a handled on the device that libinput_platform has right?02:03
bschaeferthough if it has its own libinput context...02:03
bschaefernot 100% sure how that'll work out02:03
RAOFbschaefer: Unity8 will have a libinput_platform itself.02:03
RAOFie: *both* USC and U8 will have a fully armed and operational input platform.02:03
bschaeferooo ... ok that confuses things a bit :), since i thought the platform would set under USC02:03
bschaefero geez yeah02:04
bschaeferso platform --> USC --> (platform --> U8)?02:04
RAOFThe only difference being that USC populates its platform from udev + open(), and U8 populates its platform from the fds it receives.02:04
RAOFRight. platform → USC → platform → U8.02:04
bschaeferRAOF, they would both get events at the same time thougH?02:04
bschaeferfrom the same events02:04
* bschaefer finds that strange02:04
bschaeferdoes U8 just filter out the extra events?02:05
bschaeferor listens to what it wants and ignore USC events?02:05
bschaeferim now imagining, USC handles its events02:05
bschaeferand U8 handles its events02:05
RAOFWe can either (a) have U8 not register a surface event handler, or (b) send no surface events when a client has subscribed to raw mode.02:05
bschaeferwith out much talk02:05
* bschaefer finds nested servers strange02:06
bschaeferRAOF, i think im slowly getting the idea though02:06
RAOFThis is also not very different from the status quo - it's platform → USC → (nested) platform → U8.02:06
bschaeferright but theres02:06
RAOFWe'd just be changing (a) what gets sent from USC → U8 and how the nested platform works.02:06
bschaeferUSC --> (platform) --> U8 (server) --> U8 client02:06
bschaeferi see, i didnt think there was 2 platforms02:07
bschaeferso we just need to in a sense clone the platform layer02:07
bschaeferthat sits below USC02:07
bschaeferto the nested platform?02:07
RAOFPretty much, yeah.02:07
bschaefernow how will U8 change configurations then?02:07
RAOFBy interacting with the input platform directly.02:07
bschaeferform the client?02:08
bschaeferor its nested server bit?02:08
bschaeferie. its created server will have to talk to the 'cloned' platform02:08
bschaeferand then configure it, which will then configure the fds opened by udev in USC?02:08
RAOFThe nested server bit; U8 is getting its input from its own input platform (as is currently the case) - if we send the fds over, U8's input platform can have full control over how to interpret the bits.02:09
bschaeferi see that makes much more sense02:09
RAOFThere's no configuration of the fds opened in USC.02:09
RAOFThe only configuration in the input platform is how the input platform interprets the events it gets on the fds.02:09
* bschaefer wonders how handling saved configurations will be hanlded02:09
RAOFSo if U8's input platform is reading the events from the fds, it gets to do whatever it wants with them.02:09
bschaeferthats to far up02:09
RAOFSaved configurations is *definitely* U8's job.02:10
bschaeferRAOF, so we pretty much just need to tell U8 what devices to add02:10
bschaeferto its input context02:10
bschaeferRAOF, then whats the point of sending the FD it self if we arent planning on changing the input context in USC?02:10
* bschaefer thinks a device path would be better then an FD at this poin02:10
bschaeferRAOF, but i think im missing something :)02:10
RAOFbschaefer: Because U8 can't open the device itself - if it *could* open the device itself then it can read input.02:10
bschaefero i see02:11
RAOFEven when (a) USC wants to eat that input, and more importantly (b) even when there's another session active.02:11
bschaeferRAOF, so .. the only thing im stuck on is how do we add a device to the input context with an FD :)02:12
* bschaefer will have to dig into that02:12
bschaeferwhich you were saying might not be possible02:12
RAOFIf you pass in the device path as well it'll be easy.02:12
bschaeferwith out a path, but reading libinput API it looks like add_device just needs a lib input context02:12
bschaeferit doesnt 'open' the device02:12
bschaeferit just adds it to the internal list of devices02:12
bschaeferwhich is what we want02:12
bschaeferRAOF, so yeah, i think we just need to pass a path vs needing an FD at all02:13
bschaeferlibinput_path_add_device(struct libinput *libinput,02:13
bschaefer       const char *path);02:13
RAOFRight, but that's not going to work because libinput won't be able to open the device :)02:13
RAOFThat's why we're passing in an fd.02:13
bschaeferIf the device was successfully initialized... hmm02:13
RAOFIf you do exactly that but *also* pass in an fd and use it instead of wherever libinput calls open() on that device...02:14
bschaeferyeah i need to take at look at what that means02:14
bschaeferso we'll have to figure out how to add a device with an FD and a path (which is unsupported atm)02:14
bschaeferfrom what i see02:14
RAOFAt some point in libinput_path_add_device there's going to be a call to open(/the/path) to get the fd libinput will poll on.02:14
bschaeferright, which i was missing02:15
bschaeferbut yeah we'll have to add our own function to then use the FD02:15
* bschaefer checks what else it uses that path for02:15
* bschaefer needs to re-read the backlog02:17
bschaeferas i think we covered this, but if we dont need to 'open' the device then we shouldnt need the path :)02:17
bschaeferwe just need to create a libinput_device based on that FD02:18
bschaefervs going through evdev to create a device with the path02:18
bschaefer'libinput does need a way to probe the udev properties for the device'02:19
bschaeferright which i uses the path for that02:19
bschaeferthat makes more sense now02:19
bschaeferthat is... if it really needs to probe for those and if it uses the path or fd (ill have to check)02:19
bschaeferRAOF, so after that, ill need to look at adding a new function in toolkit for a mir surface to add a raw input handler02:20
bschaefer(that should be less then a day of work)02:20
bschaeferRAOF, after that... its mainly just U8 doing the rest of the work?02:20
bschaeferin qtmir?02:21
RAOFWe then need to make the appropriate changes to the nested input platform.02:21
RAOFAnd expose the relevant configuration points out of the input platform.02:21
bschaeferthat sits in qtmir right?02:21
RAOFNah, Mir.02:21
bschaefero hmm i thought qtmir was the nested server it self02:22
bschaeferor i need to look at the nested bits that are in mir it self?02:22
RAOFqtmir uses libmirserver...02:22
bschaeferi see yeah02:22
RAOFYeah, the nested bits that are in Mir itself.02:22
bschaeferbut we have to fix the functions it uses :)02:22
bschaeferRAOF, so, ill try to focus on figuring out as much as i can with the libinput part (mainly just try to make a function that create a device based on the FD passed)02:22
RAOFqtmir (should) run fine on the bare-metal, too. The choice of platform is contained within libmirserver, not in qtmir.02:22
bschaeferand populate a valid struct02:23
RAOFYeah, that'd be a reasonable first step.02:23
bschaefercool thanks that should be fun!02:23
RAOFBecause most of the rest of this is going to be the same whether or not we do the input-bypass trick.02:23
RAOFWell, maybe not most. But we certainly need to provide the relevant configuration points from the input platform regardless.02:24
bschaeferyeah, the libinput stuff seems needed no matter way for the nested server stuff02:24
* bschaefer cant english02:24
bschaeferand its my only language :(02:24
bschaeferno matter what* for the nested server02:24
bschaeferbut ... really im not sure02:24
RAOFWe certainly need configuration points in the input platform; they'll basically just forward to the relevant libinput thing.02:28
bschaeferRAOF, this will be the API that is needed overall?02:32
bschaeferso we'll just need to forward set_cursor_accel suff?02:32
RAOFYeah, that's roughly it.02:32
bschaefercool that should just be a simple 1to1 mapping02:33
bschaeferwhich would be very nice02:33
RAOFIf we do the input-bypass, then the nested input platform can expose those easily. If we don't do input-bypass, then USC needs to expose those over DBus (or whatever).02:33
bschaeferso either or we'll need those functions02:34
RAOFI think you mean ‘so either way we'll need those functions’?02:34
RAOFAnd, yes :)02:34
bschaeferRAOF, that is what i mean02:34
* bschaefer think 'either or' means if we pick 1 or the other02:35
* bschaefer should work on english02:35
bschaeferits an xor haha02:35
bschaeferRAOF, would there be a benefit of having both implemented?02:36
RAOFKinda, maybe.02:37
bschaeferjust a thought is all (need to get more context on everything really)02:37
* RAOF luncheons02:46
=== JanC_ is now known as JanC
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
RAOFWoot! My branch fails for actual reasons!07:07
dufluRAOF: Yes, we have real sensible failures now :)07:29
* guest42315 𝖎 𝖓𝖊𝖊𝖉 𝖇𝖑𝖔𝖔𝖉!09:20
=== guest42315 is now known as drk|aw
=== greyback_ is now known as greyback|shops
=== greyback|shops is now known as greyback
alfgreyback: I noticed that on meizu with rc.proposed a long press of the power button doesn't show the power-off dialog if the screen is off when the press starts. Is this expected?10:55
greybackalf: I just tried and it worked10:55
greybackoh hang, let me try exactly what you said10:56
* greyback 's phone rebooted, suspects a trap10:56
greybackalf: I think that's a bug indeed10:57
alfgreyback: ... happened to me too, I assumed it's because I pressed the power button for too long (waiting for the dialog to appear but never did)10:58
alfgreyback: ok, I will file a bug in unity8, but I will also investigate USC in case something is going wrong there10:59
greybackalf: ok, thanks10:59
greybacknote if you're looking for stuff to do, the display configuration api for system settings would be nice ;)11:00
alfgreyback: Not actively looking, my plate is full (unless priorities change and move me to a different plate)... This bug just caught my attention and just wanted to ensure we haven't messed up USC somehow :)11:07
greybackalf: yeah understood, was just being cheeky :)11:08
alfgreyback: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1486953 , I'll check USC and if I find anything suspicious I will add the project to the bug11:11
ubot5Ubuntu bug 1486953 in unity8 (Ubuntu) "Power-off dialog doesn't show if power key press begins when screen is off" [High,New]11:11
greybackalf: ack11:11
alfgreyback: how does unity8 detect a long power-key press?11:14
greybackalf: is in unity8, qml/Components/PhysicalKeysMapper.qml - nothing too special, listens for key events, uses timer11:16
alfgreyback: ok, so it doesn't depend on USC (which makes sense, since I don't see anything in use to notify of it), which I guess rules out USC being the problem.11:17
greybackalf: probably, unless USC takes focus from the unity8 surface while display blanked11:17
alfgreyback: interesting11:18
greybackbut I do see evidence of unity8 reading display state while figuring out key long press, so that's more likely the culprit11:18
alfgreyback: yes, so // FIXME: We only consider power key presses if the screen is 74             // on because of bugs 1410830/1409003.11:20
ubot5bug 1410830 in Canonical System Image "Shutdown dialog appears on resume, after a long delay in screen turning on" [Critical,Fix released] https://launchpad.net/bugs/141083011:20
alfgreyback: "... we simply won't11:20
greybackalf: which is lame11:21
alf initiate any dialogs when the screen is off11:21
greybackwe can do that better11:21
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
alan_gAlbertA: I just spotted a 0.15 bug: there's a 9.1 stanza in client/symbols.map, but include/client/mir_toolkit/version.h has #define MIR_CLIENT_MINOR_VERSION (0) - that ought to be #define MIR_CLIENT_MINOR_VERSION (1)16:23
AlbertAalan_g: ack...will updated 0.1516:23
alan_gAlbertA: thanks16:24
=== drk|aw is now known as o
=== o is now known as Guest83769
=== alan_g is now known as alan_g|EOD
=== dandrader is now known as dandrader|afk
bschaeferRAOF, just an update, it looks like we will need the path, mainly for properties and asserting we arent a test device19:42
bschaeferas well as checking our fd opened is the same as our devnode19:42
bschaeferso far its a pretty length path down to a evdev_create (where the open happens)19:42
* bschaefer tries to figure out the smallest amount of changes needed for a libinput_device add_device_from_fd_and_path19:43
=== dandrader|afk is now known as dandrader
bschaeferalso the other issue i need to consider.... when our libinput context gets cleaned up20:23
bschaeferwe need to make sure not to close on the FD20:23
bschaefersince we didnt open it20:23
* bschaefer will probably just add something to a struct to check if we own it or not20:24
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
RAOFbschaefer: Actually, it should be fine to close the fd on cleanup.23:19
RAOFIt'll only close the local handle, and since in the case where we're cleaning up the libinput context we clearly don't expect to receive any more input, that should be fine :)23:19
bschaeferRAOF, well i was seeing suspend/resume23:20
RAOFAaah, yeah.23:20
bschaeferRAOF, o i see right on that part23:20
bschaeferwas just worried about doing a close restricted on the fd it self :)23:20
bschaeferRAOF, ill just have to work with that (and be aware of that)23:20
bschaefersince we skip open when we get the fd/path23:20
RAOFEven there we might be able to get away with it, as suspend will (probably?) happen when U8 loses focus and hence has its input fds revoked anyway?23:21
bschaeferRAOF, i think ill make note of it to check23:21
bschaeferbut go with seeing what happens first :)23:21
RAOFYeah, sounds sensible :)23:21
bschaeferRAOF, other then that... just trying to make more head way, trying to make just 1 function init  the struct it self23:22
bschaeferbut just reading code at this point23:22
bschaeferalso fixed up the attestable branch, was missing the ABI check in tools/update_package_abis.sh23:22
bschaeferand once this lands: https://code.launchpad.net/~brandontschaefer/mir/msg-auth-code-field-added/+merge/26838323:22
bschaeferi can clean up attestable and get it ready for an actual merge23:22
bschaeferwould be nice :) (i would like to get RaiseWindow working once thats landed :)23:25
bschaeferfor sdl23:25
RAOFYeah, that'd be good.23:25
* bschaefer wants to get as much SDL stuff done by 16.0423:25
bschaefersince SDL2 only stays with LTS :(23:26

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!