Conversation
* Fix misspelled function name output_destroy_notify * Fix function definition also * As well as one usage
Fix socket being logged before we have the socket
* Cleanup README.adoc * Fix issues in README.adoc Set kiwmi to lowercase. Remove unintended heading. Change "barely anything" to "almost nothing" for clarity.
6db8601 to
d475202
Compare
|
Wait! No! This version isn't sending events to lua at all. Rats. I'll see if I can fix that tomorrow... |
d475202 to
d3f4100
Compare
|
Another small problem I've noticed: if you disable a monitor using wlr-randr or whatever, the bounds for the cursor remain unchanged; you can move it off screen, into the invisible place where that monitor used to be. I'm not sure why that's happening. When we create a wlr_cursor, we associate the wlr_output_layout with it, and wlroots registers its own handler for when that layout changes. I'll need to take a closer look at some point. |
|
I believe that’s related to #62 (comment): the |
d3f4100 to
782c945
Compare
ghost
left a comment
There was a problem hiding this comment.
I suppose i can keep nitpicking forever, oh well 🤦. The main logic seems good though!
This revision untested yet, as i’ve got a dirty tree that i’m lazy to clean atm, but your changes are okay. IIRC there was some issue before with sometimes erroneously getting a new output event, so i’ll see if it’s still there or got fixed mid-way (ignore it until i report back).
kiwmi/desktop/output.c
Outdated
| void | ||
| output_layout_change_notify(struct wl_listener *listener, void *UNUSED(data)) |
There was a problem hiding this comment.
Note that this gets called also every time we modify the layout from within output_manager_configure(). Possible ideas how to deal with it:
- have some state saying whether we’re in
output_manager_configure()– if yes, return early- issue: existence of state similar to previous
kiwmi_output.enable_changed
- issue: existence of state similar to previous
- unregister the listener in
o_m_c(), re-register at the end- issue: the listener will soon be used for other purposes (i use it in my PR as well)
- (variation of previous point) unregister the listener, re-register between the 2nd loop and the final
ifs; replace theset_configuration()call with a manual emission of the event- issue: quite complicated
- keep it as it is and don’t fix what seems to work
There was a problem hiding this comment.
Should also note that the config can misbehave and change the layout from within the callback, in which case it has to be updated before being sent to clients.
There was a problem hiding this comment.
I suppose i can keep nitpicking forever, oh well .
It's okay, I do have a talent for producing extremely nitpickable work
I've opted to just move the contents of that listener into a normal function that's called in the couple of places that it's needed. Nothing should be changing the output_layout outside of this file so it should work fine (correct me if I'm wrong). Seemed simpler than having a listener that doesn't actually correspond to the event it's listening to.
There was a problem hiding this comment.
Nothing should be changing the output_layout outside of this file so it should work fine
The config can change it. And it seems pretty hard to me to get this right without removing kiwmi_output:move().
(so perhaps leave it be and add a todo? but were i the maintainer, i wouldn’t be happy merging such a thing)
There was a problem hiding this comment.
Humm, not only the config. If nested kiwmi is requested by its host compositor to resize, it also modifies the output layout without any direct action by us.
There was a problem hiding this comment.
Good spot and I forgot that the config could move outputs.
I've added output_manager_update calls for both cases (changing the size of nested compositors sets off the mode change listener, so I've put that one in there). This does make things a little less neat though.
Given that your scene graph stuff also messes around with this, I'd suggest leaving it be for now, then once you've got your scene graph code finalised, you can make an informed decision on what's the neatest way of structuring it.
There was a problem hiding this comment.
Given that your scene graph stuff also messes around with this, I'd suggest leaving it be for now, then once you've got your scene graph code finalised, you can make an informed decision on what's the neatest way of structuring it.
Well, scratch that. Looks like I've got a rebase to do.
kiwmi/desktop/output.c
Outdated
| struct kiwmi_output *output; | ||
| wl_list_for_each (output, &desktop->outputs, link) { |
There was a problem hiding this comment.
Self-note: should fix what’s iterated in my rebase (also if i rebase the scene PR onto this); then also the area!=NULL check below makes sense.
| output->wlr_output, | ||
| head->state.x, | ||
| head->state.y); | ||
| wl_signal_emit(&output->events.resize, output); |
There was a problem hiding this comment.
This event is emitted even if the output isn’t resized. I think a check similar to enable_changed would fix that. (Or should it be preserved so that all outputs emit some event?)
There was a problem hiding this comment.
The resize signal is now emitted if there are pending mode, scale or transform changes, or if head->state.x/y are different to the current values. Having moves trigger a resize event is a bit weird but I think the config should be told when an output moves and having seperate move and resize events doesn't seem worth the effort.
Seems like it got fixed and/or i remember wrongly. Edit: for the record, it’s only me being dumb again and testing my rebase rather than this PR. That wrong event was apparently caused by changes in wlroots 0.16. No need to worry for now; it can be solved when the time comes. |
This is needed in order for wlroots to interpret some values (mostly coords of absolute input events) correctly. It for example fixes how the pointer behaves with WLR_WL_OUTPUTS=2. In order to also map the pointer/output pair when the pointer is created before the output, a list of pointers has to be managed, which wasn't needed until now.
The rendered region size is independent on the output transform and scale. Until now, an output with scale > 1 would render only its (1 / scale) part; so with a scale of 2, only the top-left quarter (ie. the left 1/2 of the top 1/2) would be visible. Similarly, a portrait output (constructed as landscape, rotated by 90 degrees) would have an empty area at its bottom. This bug was found while testing the output-management PR (buffet#62).
|
The commit message also isn’t right anymore (fortunately):
|
This is basically some pre-emptive bug fixing before adding wlr_output_manager support in the next commit.
782c945 to
8916132
Compare
ghost
left a comment
There was a problem hiding this comment.
Seems okayish, only the layout change propagation is more complicated.
kiwmi/desktop/output.c
Outdated
| bool moved = output->wlr_output->pending.committed | ||
| & (WLR_OUTPUT_STATE_MODE | WLR_OUTPUT_STATE_SCALE | ||
| | WLR_OUTPUT_STATE_TRANSFORM); | ||
| struct wlr_output_layout_output *layout_output = | ||
| wlr_output_layout_get( | ||
| server->desktop.output_layout, output->wlr_output); | ||
| moved |= head->state.x != layout_output->x | ||
| || head->state.y != layout_output->y; |
There was a problem hiding this comment.
I wouldn’t be scared of making this two variables, moved & resized. Would help code understanding and also make it easier to add a separate move event to kiwmi_output if desired.
There was a problem hiding this comment.
Fair, though I'd recommend we keep moves and resizes in the same event, seeing as the vast majority of configs will be doing exactly the same thing in each case.
| if (head == bad_head) { | ||
| break; | ||
| } else { | ||
| continue; | ||
| } |
There was a problem hiding this comment.
My logic would be, if we’ve gotten here, continue, instead of either break, or continue. Seems very subjective though.
| if (head == bad_head) { | |
| break; | |
| } else { | |
| continue; | |
| } | |
| if (head == bad_head) { | |
| break; | |
| } | |
| continue; |
There was a problem hiding this comment.
If there's jumps on both outcomes of the if, I generally like to use if/else. Makes it clearer to me that the if statement is a for in the control flow rather than a detour that will rejoin.
I can change it if you'd prefer though.
This allows things like wlr-randr to work. wlr-randr or similar can send in two new events: `output_manager_apply' and `output_manager_test'. In output.c, their handler both call an new `output_manager_configure' function which loops through the list of outputs twice. The first loop applies all the requested configuration ad checks that its not all messed up. The second loop either commits that configuration or reverts it depending on whether it worked and whether we're responding to a test event. There's also now an output_manager_update function, called whenever the output layout is changed, which copies changes from the wlr_output_layout to the wlr_output_manager.
8916132 to
69507ee
Compare
The rendered region size is independent on the output transform and scale. Until now, an output with scale > 1 would render only its (1 / scale) part; so with a scale of 2, only the top-left quarter (ie. the left 1/2 of the top 1/2) would be visible. Similarly, a portrait output (constructed as landscape, rotated by 90 degrees) would have an empty area at its bottom. This bug was found while testing the output-management PR (#62).
The rendered region size is independent on the output transform and scale. Until now, an output with scale > 1 would render only its (1 / scale) part; so with a scale of 2, only the top-left quarter (ie. the left 1/2 of the top 1/2) would be visible. Similarly, a portrait output (constructed as landscape, rotated by 90 degrees) would have an empty area at its bottom. This bug was found while testing the output-management PR (#62).
The rendered region size is independent on the output transform and scale. Until now, an output with scale > 1 would render only its (1 / scale) part; so with a scale of 2, only the top-left quarter (ie. the left 1/2 of the top 1/2) would be visible. Similarly, a portrait output (constructed as landscape, rotated by 90 degrees) would have an empty area at its bottom. This bug was found while testing the output-management PR (#62).
This allows things like wlr-randr to work.
There's the standard wlroots plumbing to connect up, plus a few extra
checks here and there to make sure we're not trying to access an output
that doesn't exist anymore.