New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

i3 feature support #2

Closed
SirCmpwn opened this Issue Aug 9, 2015 · 129 comments

Comments

Projects
None yet
@SirCmpwn
Member

SirCmpwn commented Aug 9, 2015

Layouts

  • Horizontal tiling
  • Vertical tiling
  • Stacked
  • Tabbed
  • Floating
  • Saving layouts to disk will not support
  • Loading layouts from disk will not support

Config/commands

  • Config parser
  • Variables/set
  • bindsym
    • mouse bindings
    • --release
  • bindcode
    • --release
  • focus_follows_mouse
  • exit
  • exec
  • exec_always
  • fullscreen
  • workspace
    • left/right/up/down
    • number
    • next/prev
    • next_on_output/prev_on_output
    • <name>
    • <name> output <output>
    • back_and_forth
  • splith/splitv
  • focus
    • left/right/up/down
    • parent
    • mode_toggle
  • move
    • left/right/up/down
    • workspace to output
      • left/right/up/down
      • named output
    • position
  • kill
  • mode
  • layout
    • stacking
    • tabbed
    • splith
    • splitv
    • toggle split
  • bar
  • floating toggle
  • floating_modifier
  • for_window
  • font
  • default_orientation
  • workspace_layout
  • assign
  • popup_during_fullscreen
  • force_focus_wrapping
  • workspace_auto_back_and_forth
  • scratchpad
    • move scratchpad
    • scratchpad show
  • resize
    • grow
    • shrink
  • move position mouse
  • sticky toggle
  • show_marks
  • no_focus

Features

  • IPC
  • Restart in-place
  • Reload config on the fly
  • Resize containers with mouse
  • Command line options
  • Ignore i3 commands that aren't valid (i.e. force_xinerama)
  • swaybar
  • swaylock - usable, but incomplete
  • swaymsg
  • borders
  • color customization
  • Mode_switch
  • gaps
  • [criteria] command

See also:

IPC feature support: #98
i3bar feature support: #343
i3-gaps feature support: #307

@onny

This comment has been minimized.

Show comment
Hide comment
@onny

onny Aug 9, 2015

Nice write up! Especially looking for a i3 statusbar

onny commented Aug 9, 2015

Nice write up! Especially looking for a i3 statusbar

@SirCmpwn

This comment has been minimized.

Show comment
Hide comment
@SirCmpwn

SirCmpwn Aug 9, 2015

Member

It'll probably be a while before I tackle i3bar (swaybar?)

Member

SirCmpwn commented Aug 9, 2015

It'll probably be a while before I tackle i3bar (swaybar?)

@SirCmpwn

This comment has been minimized.

Show comment
Hide comment
@SirCmpwn

SirCmpwn Aug 9, 2015

Member

exec implemented.

Member

SirCmpwn commented Aug 9, 2015

exec implemented.

SirCmpwn added a commit that referenced this issue Aug 9, 2015

@SirCmpwn

This comment has been minimized.

Show comment
Hide comment
@SirCmpwn

SirCmpwn Aug 10, 2015

Member

Today we implemented splith, splitv, fullscreen, and focus. Thanks for helping out, @jdiez17!

Member

SirCmpwn commented Aug 10, 2015

Today we implemented splith, splitv, fullscreen, and focus. Thanks for helping out, @jdiez17!

@jdiez17

This comment has been minimized.

Show comment
Hide comment
@jdiez17

jdiez17 Aug 10, 2015

Contributor

workspace [name] done.

Contributor

jdiez17 commented Aug 10, 2015

workspace [name] done.

@progandy

This comment has been minimized.

Show comment
Hide comment
@progandy

progandy Aug 16, 2015

Contributor

You forgot the scratchpad functionality.

Contributor

progandy commented Aug 16, 2015

You forgot the scratchpad functionality.

@SirCmpwn

This comment has been minimized.

Show comment
Hide comment
@SirCmpwn

SirCmpwn Aug 16, 2015

Member

Good call.

Member

SirCmpwn commented Aug 16, 2015

Good call.

@Swoorup

This comment has been minimized.

Show comment
Hide comment
@Swoorup

Swoorup Aug 18, 2015

Nice, I have been looking at i3way but there's no single line of code after so many years.

I want to propose a feature request though, which i3 developers ignored: A tiling mode for binary space layout representing windows as the leaves of a full binary tree, very similar to default window tiling mode that comes with bspwm. It could be very handy letting the software manage my windows(specially terminals) instead of managing the arrangement in a single desktop. I don't want to break any compatibility though so I am hoping it does not.

Also an option to set the gap between windows would be nice. This was done in i3 but by a third party git fork. I don't know why it was deemed not a necessity by i3 developers.

BTW This project should also get its own website.

Swoorup commented Aug 18, 2015

Nice, I have been looking at i3way but there's no single line of code after so many years.

I want to propose a feature request though, which i3 developers ignored: A tiling mode for binary space layout representing windows as the leaves of a full binary tree, very similar to default window tiling mode that comes with bspwm. It could be very handy letting the software manage my windows(specially terminals) instead of managing the arrangement in a single desktop. I don't want to break any compatibility though so I am hoping it does not.

Also an option to set the gap between windows would be nice. This was done in i3 but by a third party git fork. I don't know why it was deemed not a necessity by i3 developers.

BTW This project should also get its own website.

@SirCmpwn

This comment has been minimized.

Show comment
Hide comment
@SirCmpwn

SirCmpwn Aug 18, 2015

Member

I want to propose a feature request though, which i3 developers ignored: A tiling mode for binary space layout representing windows as the leaves of a full binary tree, very similar to default window tiling mode that comes with bspwm. It could be very handy letting the software manage my windows(specially terminals) instead of managing the arrangement in a single desktop. I don't want to break any compatibility though so I am hoping it does not.

Perhaps eventually. That doesn't sound like it needs to be a high priority.

Also an option to set the gap between windows would be nice. This was done in i3 but by a third party git fork. I don't know why it was deemed not a necessity by i3 developers.

This is in the list of features to add.

BTW This project should also get its own website.

Yeah, it'll have one eventually.

Member

SirCmpwn commented Aug 18, 2015

I want to propose a feature request though, which i3 developers ignored: A tiling mode for binary space layout representing windows as the leaves of a full binary tree, very similar to default window tiling mode that comes with bspwm. It could be very handy letting the software manage my windows(specially terminals) instead of managing the arrangement in a single desktop. I don't want to break any compatibility though so I am hoping it does not.

Perhaps eventually. That doesn't sound like it needs to be a high priority.

Also an option to set the gap between windows would be nice. This was done in i3 but by a third party git fork. I don't know why it was deemed not a necessity by i3 developers.

This is in the list of features to add.

BTW This project should also get its own website.

Yeah, it'll have one eventually.

@Half-Shot

This comment has been minimized.

Show comment
Hide comment
@Half-Shot

Half-Shot Aug 18, 2015

Contributor

Also an option to set the gap between windows would be nice. This was done in i3 but by a third >party git fork. I don't know why it was deemed not a necessity by i3 developers.

Due to it not fitting the i3 way, which means using all the screen space. I can understand why, but that doesn't mean this project has to enforce the same rules.

Contributor

Half-Shot commented Aug 18, 2015

Also an option to set the gap between windows would be nice. This was done in i3 but by a third >party git fork. I don't know why it was deemed not a necessity by i3 developers.

Due to it not fitting the i3 way, which means using all the screen space. I can understand why, but that doesn't mean this project has to enforce the same rules.

@Half-Shot

This comment has been minimized.

Show comment
Hide comment
@Half-Shot

Half-Shot Aug 18, 2015

Contributor

Will have a go at the move command. Should have some results tonight.

Contributor

Half-Shot commented Aug 18, 2015

Will have a go at the move command. Should have some results tonight.

@robinmoussu

This comment has been minimized.

Show comment
Hide comment
@robinmoussu

robinmoussu Aug 18, 2015

Hi. I want to propose a feature request: vertical bar. I think the easiest way is to only do a 90° rotation. The text orientation should be configurable: bottom to top, or top to bottom.

robinmoussu commented Aug 18, 2015

Hi. I want to propose a feature request: vertical bar. I think the easiest way is to only do a 90° rotation. The text orientation should be configurable: bottom to top, or top to bottom.

@SirCmpwn

This comment has been minimized.

Show comment
Hide comment
@SirCmpwn

SirCmpwn Aug 18, 2015

Member

Will consider that once we hit feature parity with i3.

Member

SirCmpwn commented Aug 18, 2015

Will consider that once we hit feature parity with i3.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Aug 18, 2015

Sway looks like a really great project. I love i3, and the lack of something similar is the only thing that has been stopping me from giving Wayland a try. Great work so far!

However, looking at the list above, I see that sway is still missing tabbed layout, which is essential for my workflow; I use it heavily in i3. This is the main thing stopping me from trying out sway at this point. I could live without the other missing features.

Once tabbed layout is done, I will try playing around with sway. I am really looking forward to it. Hope to catch/report some bugs and maybe contribute some patches.

I honestly think this project has the potential to eventually become even better than i3.

ghost commented Aug 18, 2015

Sway looks like a really great project. I love i3, and the lack of something similar is the only thing that has been stopping me from giving Wayland a try. Great work so far!

However, looking at the list above, I see that sway is still missing tabbed layout, which is essential for my workflow; I use it heavily in i3. This is the main thing stopping me from trying out sway at this point. I could live without the other missing features.

Once tabbed layout is done, I will try playing around with sway. I am really looking forward to it. Hope to catch/report some bugs and maybe contribute some patches.

I honestly think this project has the potential to eventually become even better than i3.

@SirCmpwn

This comment has been minimized.

Show comment
Hide comment
@SirCmpwn

SirCmpwn Aug 18, 2015

Member

The tabbed layout is sort of blocked by the lack of borders.

Member

SirCmpwn commented Aug 18, 2015

The tabbed layout is sort of blocked by the lack of borders.

@Airblader

This comment has been minimized.

Show comment
Hide comment
@Airblader

Airblader Aug 18, 2015

@Swoorup This is off-topic, but

This was done in i3 but by a third party git fork. I don't know why it was deemed not a necessity by i3 developers.

We don't want this in i3 for many reasons. For one, the i3-gaps patch (of which I am the maintainer) is really more of a hack (for example, window decorations don't work with it). But that could be solved. However, gaps violate the i3 tiling philosophy and that is why they will never be found in i3 itself.

Being a collaborator of i3 I understand this reasoning, being the maintainer of i3-gaps I obviously personally prefer gaps, though. ;)

Airblader commented Aug 18, 2015

@Swoorup This is off-topic, but

This was done in i3 but by a third party git fork. I don't know why it was deemed not a necessity by i3 developers.

We don't want this in i3 for many reasons. For one, the i3-gaps patch (of which I am the maintainer) is really more of a hack (for example, window decorations don't work with it). But that could be solved. However, gaps violate the i3 tiling philosophy and that is why they will never be found in i3 itself.

Being a collaborator of i3 I understand this reasoning, being the maintainer of i3-gaps I obviously personally prefer gaps, though. ;)

@Half-Shot

This comment has been minimized.

Show comment
Hide comment
@Half-Shot

Half-Shot Aug 19, 2015

Contributor

Would it be sensible to have our own wallpaper management, or somehow hook into a process like feh?
(and as on a sidenote, how would I hint to sway/wlc that a surface should be drawn behind everything?)

Contributor

Half-Shot commented Aug 19, 2015

Would it be sensible to have our own wallpaper management, or somehow hook into a process like feh?
(and as on a sidenote, how would I hint to sway/wlc that a surface should be drawn behind everything?)

@SirCmpwn

This comment has been minimized.

Show comment
Hide comment
@SirCmpwn

SirCmpwn Aug 19, 2015

Member

No, we'll have something like feh for you to use instead.

Member

SirCmpwn commented Aug 19, 2015

No, we'll have something like feh for you to use instead.

@SirCmpwn

This comment has been minimized.

Show comment
Hide comment
@SirCmpwn

SirCmpwn Aug 19, 2015

Member

And you can't do that hinting, I've been asking @Cloudef for it in wlc for a while.

Member

SirCmpwn commented Aug 19, 2015

And you can't do that hinting, I've been asking @Cloudef for it in wlc for a while.

@minus7 minus7 referenced this issue Aug 21, 2015

Closed

Scratchpad #115

@tiregram

This comment has been minimized.

Show comment
Hide comment
@tiregram

tiregram Sep 10, 2015

hi,
can you add the support to layout keyboard azerty.

tiregram commented Sep 10, 2015

hi,
can you add the support to layout keyboard azerty.

@SirCmpwn

This comment has been minimized.

Show comment
Hide comment
@SirCmpwn

SirCmpwn Sep 10, 2015

Member

That's not really our problem, it's wlc's problem. And wlc let's you set it through XKB environment variables, XKB_DEFAULT_LAYOUT.

Member

SirCmpwn commented Sep 10, 2015

That's not really our problem, it's wlc's problem. And wlc let's you set it through XKB environment variables, XKB_DEFAULT_LAYOUT.

@progandy

This comment has been minimized.

Show comment
Hide comment
@progandy

progandy Sep 10, 2015

Contributor

@SirCmpwn In the longterm, sway should implement configuration options for input and output devices, but that has to wait until wlc implements an API for that. Maybe even provide some ipc options to allow dynamic changes like xinput/xrandr.
Cloudef/wlc#6
Cloudef/wlc#37

Contributor

progandy commented Sep 10, 2015

@SirCmpwn In the longterm, sway should implement configuration options for input and output devices, but that has to wait until wlc implements an API for that. Maybe even provide some ipc options to allow dynamic changes like xinput/xrandr.
Cloudef/wlc#6
Cloudef/wlc#37

@Luminarys

This comment has been minimized.

Show comment
Hide comment
@Luminarys

Luminarys Sep 10, 2015

Collaborator

Sway already does provide configuration options to alter the size, position, and status(on/off) of monitors. As of right now dynamic changes are not available though.

Collaborator

Luminarys commented Sep 10, 2015

Sway already does provide configuration options to alter the size, position, and status(on/off) of monitors. As of right now dynamic changes are not available though.

@tiregram

This comment has been minimized.

Show comment
Hide comment
@tiregram

tiregram Sep 12, 2015

Sorry , but the other keyboard are not supported on my pc (fr).
I know i just need to export XKB_DEFAULT_LAYOUT=fr
But i can't use number to switch to other worspace, because on fr keyboard the "1" is "&" and & was forbiden.
Message log:
Bindsym - unknow key &.
Can you help me ?

tiregram commented Sep 12, 2015

Sorry , but the other keyboard are not supported on my pc (fr).
I know i just need to export XKB_DEFAULT_LAYOUT=fr
But i can't use number to switch to other worspace, because on fr keyboard the "1" is "&" and & was forbiden.
Message log:
Bindsym - unknow key &.
Can you help me ?

@Half-Shot

This comment has been minimized.

Show comment
Hide comment
@Half-Shot

Half-Shot Sep 12, 2015

Contributor

I used to use bindcode in i3 for unknown symbols. I'm guessing another wlc feature.
On 12 Sep 2015 11:54, tiregram notifications@github.com wrote:Sorry , but the other keyboard are not supported on my pc (fr).
I know i just need to export XKB_DEFAULT_LAYOUT=fr
But i can't use number to switch to other worspace, because on fr keyboard the "1" is "&" and & was forbiden.
Message log:
Bindsym - unknow key &.
Can you help me ?

—Reply to this email directly or view it on GitHub.

Contributor

Half-Shot commented Sep 12, 2015

I used to use bindcode in i3 for unknown symbols. I'm guessing another wlc feature.
On 12 Sep 2015 11:54, tiregram notifications@github.com wrote:Sorry , but the other keyboard are not supported on my pc (fr).
I know i just need to export XKB_DEFAULT_LAYOUT=fr
But i can't use number to switch to other worspace, because on fr keyboard the "1" is "&" and & was forbiden.
Message log:
Bindsym - unknow key &.
Can you help me ?

—Reply to this email directly or view it on GitHub.

@SirCmpwn

This comment has been minimized.

Show comment
Hide comment
@SirCmpwn

SirCmpwn Sep 12, 2015

Member

bindcode isn't supported on sway yet. Try binding "ampersand".

Member

SirCmpwn commented Sep 12, 2015

bindcode isn't supported on sway yet. Try binding "ampersand".

@tiregram

This comment has been minimized.

Show comment
Hide comment
@tiregram

tiregram Sep 13, 2015

yes i have try but i have the message.
Bindsym - unknow key &
on the tty, this message error was genenrate by the line:
command.c:154
because you check
xkb_keysym_from_name(split->items[i], XKB_KEYSYM_CASE_INSENSITIVE);

tiregram commented Sep 13, 2015

yes i have try but i have the message.
Bindsym - unknow key &
on the tty, this message error was genenrate by the line:
command.c:154
because you check
xkb_keysym_from_name(split->items[i], XKB_KEYSYM_CASE_INSENSITIVE);

@SirCmpwn

This comment has been minimized.

Show comment
Hide comment
@SirCmpwn

SirCmpwn Oct 28, 2015

Member

Updated with features from i3 4.11.

Member

SirCmpwn commented Oct 28, 2015

Updated with features from i3 4.11.

@talwrii

This comment has been minimized.

Show comment
Hide comment
@talwrii

talwrii Jan 1, 2018

Saving layouts to disk will not support
Loading layouts from disk will not support

I use that feature in i3 :/ .

I imagine it isn't too hard to implement this outside of i3 using i3-msg.

Is i3-msg -t get_tree still going to be supported?

talwrii commented Jan 1, 2018

Saving layouts to disk will not support
Loading layouts from disk will not support

I use that feature in i3 :/ .

I imagine it isn't too hard to implement this outside of i3 using i3-msg.

Is i3-msg -t get_tree still going to be supported?

@SirCmpwn

This comment has been minimized.

Show comment
Hide comment
@SirCmpwn

SirCmpwn Jan 1, 2018

Member

Yes, get_tree already works and has worked for some time.

Member

SirCmpwn commented Jan 1, 2018

Yes, get_tree already works and has worked for some time.

@sharpTrick

This comment has been minimized.

Show comment
Hide comment
@sharpTrick

sharpTrick Jan 23, 2018

I made a script that may be useful for

  • workspace
    • left/right/up/down

https://github.com/sharpTrick/set-i3-workspace

sharpTrick commented Jan 23, 2018

I made a script that may be useful for

  • workspace
    • left/right/up/down

https://github.com/sharpTrick/set-i3-workspace

@hyiltiz

This comment has been minimized.

Show comment
Hide comment
@hyiltiz

hyiltiz Jan 26, 2018

Nice work! Expecting "Restart in-place".

hyiltiz commented Jan 26, 2018

Nice work! Expecting "Restart in-place".

@ammgws

This comment has been minimized.

Show comment
Hide comment
@ammgws

ammgws Jan 27, 2018

Contributor

@progandy

I use that for my keybindings so that I can easily rename a workspace while keepig the hotkey.

Could you please clarify how you are renaming workspaces in sway? swaymsg doesn't appear to support the rename command (e.g. in i3: i3-msg 'rename workspace 5 to 6')

Contributor

ammgws commented Jan 27, 2018

@progandy

I use that for my keybindings so that I can easily rename a workspace while keepig the hotkey.

Could you please clarify how you are renaming workspaces in sway? swaymsg doesn't appear to support the rename command (e.g. in i3: i3-msg 'rename workspace 5 to 6')

@progandy

This comment has been minimized.

Show comment
Hide comment
@progandy

progandy Jan 27, 2018

Contributor

@ammgws

Could you please clarify how you are renaming workspaces in sway?

In most cases I start with a fresh workspace and give it a name, e.g. swaymsg workspace 5:new_project. My main environment is still i3, though. If I really have to do it in sway, then I can do something like this.

#!/bin/bash
topfocus=""
for i in {1..20}; do
   topfocus="focus parent ; $topfocus"
done
swaymsg "$topfocus" move container to workspace "$1" ';' workspace "$1"
Contributor

progandy commented Jan 27, 2018

@ammgws

Could you please clarify how you are renaming workspaces in sway?

In most cases I start with a fresh workspace and give it a name, e.g. swaymsg workspace 5:new_project. My main environment is still i3, though. If I really have to do it in sway, then I can do something like this.

#!/bin/bash
topfocus=""
for i in {1..20}; do
   topfocus="focus parent ; $topfocus"
done
swaymsg "$topfocus" move container to workspace "$1" ';' workspace "$1"
@ammgws

This comment has been minimized.

Show comment
Hide comment
@ammgws

ammgws Jan 28, 2018

Contributor

Cheers, I guess that's what I'll have to do for now.

Contributor

ammgws commented Jan 28, 2018

Cheers, I guess that's what I'll have to do for now.

@hyiltiz

This comment has been minimized.

Show comment
Hide comment
@hyiltiz

hyiltiz Jan 28, 2018

@progandy why the loop that does nothing but set a variable?

hyiltiz commented Jan 28, 2018

@progandy why the loop that does nothing but set a variable?

@progandy

This comment has been minimized.

Show comment
Hide comment
@progandy

progandy Jan 29, 2018

Contributor

@hyiltiz that should add instead of replace... topfocus="focus parent ; $topfocus"

Contributor

progandy commented Jan 29, 2018

@hyiltiz that should add instead of replace... topfocus="focus parent ; $topfocus"

@emersion emersion referenced this issue Mar 31, 2018

Merged

I3bar json #1690

@coderkun

This comment has been minimized.

Show comment
Hide comment
@coderkun

coderkun Apr 2, 2018

Contributor

Is moving a workspace left/right/up/down still not supported?

Contributor

coderkun commented Apr 2, 2018

Is moving a workspace left/right/up/down still not supported?

@SirCmpwn

This comment has been minimized.

Show comment
Hide comment
@SirCmpwn

SirCmpwn Apr 2, 2018

Member

It's supported in the wlroots branch, at least. Not sure about 0.x.

Member

SirCmpwn commented Apr 2, 2018

It's supported in the wlroots branch, at least. Not sure about 0.x.

@coderkun

This comment has been minimized.

Show comment
Hide comment
@coderkun

coderkun Apr 2, 2018

Contributor

Thanks, @SirCmpwn. It is good to know that it will be supported with 1.x.

Contributor

coderkun commented Apr 2, 2018

Thanks, @SirCmpwn. It is good to know that it will be supported with 1.x.

martinetd added a commit to martinetd/sway that referenced this issue Jun 26, 2018

layer_shell: cleanup output link on output destroy
Fixes this kind of use-after-free:
==1795==ERROR: AddressSanitizer: heap-use-after-free on address 0x612000191ef0 at pc 0x00000048c388 bp 0x7ffe308f0410 sp 0x7ffe308f0400
WRITE of size 8 at 0x612000191ef0 thread T0
    #0 0x48c387 in wl_list_remove ../common/list.c:157
    swaywm#1 0x42196b in handle_destroy ../sway/desktop/layer_shell.c:275
    swaywm#2 0x7f55cc2549fa in wlr_signal_emit_safe ../util/signal.c:29
    swaywm#3 0x7f55cc22cf68 in layer_surface_destroy ../types/wlr_layer_shell.c:182
    swaywm#4 0x7f55cc22d084 in layer_surface_resource_destroy ../types/wlr_layer_shell.c:196
    swaywm#5 0x7f55cc4ca025 in destroy_resource src/wayland-server.c:688
    swaywm#6 0x7f55cc4ca091 in wl_resource_destroy src/wayland-server.c:705
    swaywm#7 0x7f55cc22c3a2 in resource_handle_destroy ../types/wlr_layer_shell.c:18
    swaywm#8 0x7f55c8ef103d in ffi_call_unix64 (/lib64/libffi.so.6+0x603d)
    swaywm#9 0x7f55c8ef09fe in ffi_call (/lib64/libffi.so.6+0x59fe)
    swaywm#10 0x7f55cc4cdf2c  (/lib64/libwayland-server.so.0+0xbf2c)
    swaywm#11 0x7f55cc4ca3de in wl_client_connection_data src/wayland-server.c:420
    swaywm#12 0x7f55cc4cbf01 in wl_event_loop_dispatch src/event-loop.c:641
    swaywm#13 0x7f55cc4ca601 in wl_display_run src/wayland-server.c:1260
    swaywm#14 0x40bb1e in server_run ../sway/server.c:141
    swaywm#15 0x40ab2f in main ../sway/main.c:432
    swaywm#16 0x7f55cb97318a in __libc_start_main ../csu/libc-start.c:308
    swaywm#17 0x408d29 in _start (/opt/wayland/bin/sway+0x408d29)

0x612000191ef0 is located 48 bytes inside of 312-byte region [0x612000191ec0,0x612000191ff8)
freed by thread T0 here:
    #0 0x7f55ce3bb880 in __interceptor_free (/lib64/libasan.so.5+0xee880)
    swaywm#1 0x42f1db in handle_destroy ../sway/desktop/output.c:1275
    swaywm#2 0x7f55cc2549fa in wlr_signal_emit_safe ../util/signal.c:29
    swaywm#3 0x7f55cc23b4c2 in wlr_output_destroy ../types/wlr_output.c:284
    swaywm#4 0x7f55cc1ddc20 in xdg_toplevel_handle_close ../backend/wayland/output.c:235
    swaywm#5 0x7f55c8ef103d in ffi_call_unix64 (/lib64/libffi.so.6+0x603d)

previously allocated by thread T0 here:
    #0 0x7f55ce3bbe50 in calloc (/lib64/libasan.so.5+0xeee50)
    swaywm#1 0x42f401 in handle_new_output ../sway/desktop/output.c:1308
    swaywm#2 0x7f55cc2549fa in wlr_signal_emit_safe ../util/signal.c:29
    swaywm#3 0x7f55cc1d6cbf in new_output_reemit ../backend/multi/backend.c:113
    swaywm#4 0x7f55cc2549fa in wlr_signal_emit_safe ../util/signal.c:29
    swaywm#5 0x7f55cc1deac7 in wlr_wl_output_create ../backend/wayland/output.c:327
    swaywm#6 0x7f55cc1db353 in backend_start ../backend/wayland/backend.c:55
    swaywm#7 0x7f55cc1bad55 in wlr_backend_start ../backend/backend.c:35
    swaywm#8 0x7f55cc1d67a0 in multi_backend_start ../backend/multi/backend.c:24
    swaywm#9 0x7f55cc1bad55 in wlr_backend_start ../backend/backend.c:35
    swaywm#10 0x40ba8a in server_run ../sway/server.c:136
    swaywm#11 0x40ab2f in main ../sway/main.c:432
    swaywm#12 0x7f55cb97318a in __libc_start_main ../csu/libc-start.c:308

martinetd added a commit to martinetd/sway that referenced this issue Jun 30, 2018

xdg_shell: listen to fullscreen request on map
That event comes from the toplevel and not the surface, so would cause
a use-after-free on destroy if the toplevel got destroyed first:

==5454==ERROR: AddressSanitizer: heap-use-after-free on address 0x6110001ed198 at pc 0x000000472d10 bp 0x7ffc19070a80 sp 0x7ffc19070a70
WRITE of size 8 at 0x6110001ed198 thread T0
    #0 0x472d0f in wl_list_remove ../common/list.c:157
    swaywm#1 0x42e159 in handle_destroy ../sway/desktop/xdg_shell_v6.c:243
    swaywm#2 0x7fa9e5b28ce8 in wlr_signal_emit_safe ../util/signal.c:29
    swaywm#3 0x7fa9e5afd6b1 in destroy_xdg_surface_v6 ../types/xdg_shell_v6/wlr_xdg_surface_v6.c:101
    swaywm#4 0x7fa9e5d98025 in destroy_resource src/wayland-server.c:688
    swaywm#5 0x7fa9e5d98091 in wl_resource_destroy src/wayland-server.c:705
    swaywm#6 0x7fa9e27f103d in ffi_call_unix64 (/lib64/libffi.so.6+0x603d)
    swaywm#7 0x7fa9e27f09fe in ffi_call (/lib64/libffi.so.6+0x59fe)
    swaywm#8 0x7fa9e5d9bf2c  (/lib64/libwayland-server.so.0+0xbf2c)
    swaywm#9 0x7fa9e5d983de in wl_client_connection_data src/wayland-server.c:420
    swaywm#10 0x7fa9e5d99f01 in wl_event_loop_dispatch src/event-loop.c:641
    swaywm#11 0x7fa9e5d98601 in wl_display_run src/wayland-server.c:1260
    swaywm#12 0x40a2f4 in main ../sway/main.c:433
    swaywm#13 0x7fa9e527318a in __libc_start_main ../csu/libc-start.c:308
    swaywm#14 0x40b749 in _start (/opt/wayland/bin/sway+0x40b749)

0x6110001ed198 is located 152 bytes inside of 240-byte region [0x6110001ed100,0x6110001ed1f0)
freed by thread T0 here:
    #0 0x7fa9e7c89880 in __interceptor_free (/lib64/libasan.so.5+0xee880)
    swaywm#1 0x7fa9e5affce9 in destroy_xdg_toplevel_v6 ../types/xdg_shell_v6/wlr_xdg_toplevel_v6.c:23
    swaywm#2 0x7fa9e5d98025 in destroy_resource src/wayland-server.c:688

previously allocated by thread T0 here:
    #0 0x7fa9e7c89e50 in calloc (/lib64/libasan.so.5+0xeee50)
    swaywm#1 0x7fa9e5b00eea in create_xdg_toplevel_v6 ../types/xdg_shell_v6/wlr_xdg_toplevel_v6.c:427
    swaywm#2 0x7fa9e27f103d in ffi_call_unix64 (/lib64/libffi.so.6+0x603d)

The toplevel only notifies the compositor on destroy if it was mapped,
so only listen to events at map time.

martinetd added a commit to martinetd/sway that referenced this issue Jul 4, 2018

ipc-server: add display destroy listener
wl_event_source_remove() is illegal after display has been destroyed

==20392==ERROR: AddressSanitizer: heap-use-after-free on address 0x607000001240 at pc 0x00000048e86e bp 0x7ffe4b557e00 sp 0x7ffe4b557df0
READ of size 8 at 0x607000001240 thread T0
    #0 0x48e86d in wl_list_insert ../common/list.c:149
    swaywm#1 0x7fdf673d4d7d in wl_event_source_remove src/event-loop.c:487
    swaywm#2 0x41b742 in ipc_terminate ../sway/ipc-server.c:94
    swaywm#3 0x40b1ad in main ../sway/main.c:440
    swaywm#4 0x7fdf6664c18a in __libc_start_main ../csu/libc-start.c:308
    swaywm#5 0x409359 in _start (/opt/wayland/bin/sway+0x409359)

0x607000001240 is located 48 bytes inside of 72-byte region [0x607000001210,0x607000001258)
freed by thread T0 here:
    #0 0x7fdf692c4880 in __interceptor_free (/lib64/libasan.so.5+0xee880)
    swaywm#1 0x7fdf673d371a in wl_display_destroy src/wayland-server.c:1097

previously allocated by thread T0 here:
    #0 0x7fdf692c4c48 in malloc (/lib64/libasan.so.5+0xeec48)
    swaywm#1 0x7fdf673d4d9e in wl_event_loop_create src/event-loop.c:522
    swaywm#2 0x40acb2 in main ../sway/main.c:363
    swaywm#3 0x7fdf6664c18a in __libc_start_main ../csu/libc-start.c:308

martinetd added a commit to martinetd/sway that referenced this issue Jul 4, 2018

ipc-server: add display destroy listener
wl_event_source_remove() is illegal after display has been destroyed

==20392==ERROR: AddressSanitizer: heap-use-after-free on address 0x607000001240 at pc 0x00000048e86e bp 0x7ffe4b557e00 sp 0x7ffe4b557df0
READ of size 8 at 0x607000001240 thread T0
    #0 0x48e86d in wl_list_insert ../common/list.c:149
    swaywm#1 0x7fdf673d4d7d in wl_event_source_remove src/event-loop.c:487
    swaywm#2 0x41b742 in ipc_terminate ../sway/ipc-server.c:94
    swaywm#3 0x40b1ad in main ../sway/main.c:440
    swaywm#4 0x7fdf6664c18a in __libc_start_main ../csu/libc-start.c:308
    swaywm#5 0x409359 in _start (/opt/wayland/bin/sway+0x409359)

0x607000001240 is located 48 bytes inside of 72-byte region [0x607000001210,0x607000001258)
freed by thread T0 here:
    #0 0x7fdf692c4880 in __interceptor_free (/lib64/libasan.so.5+0xee880)
    swaywm#1 0x7fdf673d371a in wl_display_destroy src/wayland-server.c:1097

previously allocated by thread T0 here:
    #0 0x7fdf692c4c48 in malloc (/lib64/libasan.so.5+0xeec48)
    swaywm#1 0x7fdf673d4d9e in wl_event_loop_create src/event-loop.c:522
    swaywm#2 0x40acb2 in main ../sway/main.c:363
    swaywm#3 0x7fdf6664c18a in __libc_start_main ../csu/libc-start.c:308

martinetd added a commit to martinetd/sway that referenced this issue Jul 4, 2018

ipc-server: add display destroy listener and remove ipc_terminate
wl_event_source_remove() is illegal after display has been destroyed,
so just destroy everything when we still can.

==20392==ERROR: AddressSanitizer: heap-use-after-free on address 0x607000001240 at pc 0x00000048e86e bp 0x7ffe4b557e00 sp 0x7ffe4b557df0
READ of size 8 at 0x607000001240 thread T0
    #0 0x48e86d in wl_list_insert ../common/list.c:149
    swaywm#1 0x7fdf673d4d7d in wl_event_source_remove src/event-loop.c:487
    swaywm#2 0x41b742 in ipc_terminate ../sway/ipc-server.c:94
    swaywm#3 0x40b1ad in main ../sway/main.c:440
    swaywm#4 0x7fdf6664c18a in __libc_start_main ../csu/libc-start.c:308
    swaywm#5 0x409359 in _start (/opt/wayland/bin/sway+0x409359)

0x607000001240 is located 48 bytes inside of 72-byte region [0x607000001210,0x607000001258)
freed by thread T0 here:
    #0 0x7fdf692c4880 in __interceptor_free (/lib64/libasan.so.5+0xee880)
    swaywm#1 0x7fdf673d371a in wl_display_destroy src/wayland-server.c:1097

previously allocated by thread T0 here:
    #0 0x7fdf692c4c48 in malloc (/lib64/libasan.so.5+0xeec48)
    swaywm#1 0x7fdf673d4d9e in wl_event_loop_create src/event-loop.c:522
    swaywm#2 0x40acb2 in main ../sway/main.c:363
    swaywm#3 0x7fdf6664c18a in __libc_start_main ../csu/libc-start.c:308

martinetd added a commit to martinetd/sway that referenced this issue Jul 4, 2018

ipc-server: add display destroy listener and remove ipc_terminate
wl_event_source_remove() is illegal after display has been destroyed,
so just destroy everything when we still can.

==20392==ERROR: AddressSanitizer: heap-use-after-free on address 0x607000001240 at pc 0x00000048e86e bp 0x7ffe4b557e00 sp 0x7ffe4b557df0
READ of size 8 at 0x607000001240 thread T0
    #0 0x48e86d in wl_list_insert ../common/list.c:149
    swaywm#1 0x7fdf673d4d7d in wl_event_source_remove src/event-loop.c:487
    swaywm#2 0x41b742 in ipc_terminate ../sway/ipc-server.c:94
    swaywm#3 0x40b1ad in main ../sway/main.c:440
    swaywm#4 0x7fdf6664c18a in __libc_start_main ../csu/libc-start.c:308
    swaywm#5 0x409359 in _start (/opt/wayland/bin/sway+0x409359)

0x607000001240 is located 48 bytes inside of 72-byte region [0x607000001210,0x607000001258)
freed by thread T0 here:
    #0 0x7fdf692c4880 in __interceptor_free (/lib64/libasan.so.5+0xee880)
    swaywm#1 0x7fdf673d371a in wl_display_destroy src/wayland-server.c:1097

previously allocated by thread T0 here:
    #0 0x7fdf692c4c48 in malloc (/lib64/libasan.so.5+0xeec48)
    swaywm#1 0x7fdf673d4d9e in wl_event_loop_create src/event-loop.c:522
    swaywm#2 0x40acb2 in main ../sway/main.c:363
    swaywm#3 0x7fdf6664c18a in __libc_start_main ../csu/libc-start.c:308

martinetd added a commit to martinetd/sway that referenced this issue Oct 7, 2018

swaynag: fix use-after-fere in wl_display_dispatch
When destroying swaynag from within wl_display_dispatch, we cannot
disconnect the display as that will free the queue's event_list.
Free it after running the loop instead.

Fixes this use-after-free (you need a wayland compiled with asan,
my wl_list hack, or running with valgrind to see this trace):
==7312==ERROR: AddressSanitizer: heap-use-after-free on address 0x612000000110 at pc 0x000000412a9f bp 0x7ffd4e811760 sp 0x7ffd4e811750
READ of size 8 at 0x612000000110 thread T0
    #0 0x412a9e in wl_list_empty ../common/list.c:206
    swaywm#1 0x7f5b58f0d42f in dispatch_queue src/wayland-client.c:1572
    swaywm#2 0x7f5b58f0d42f in wl_display_dispatch_queue_pending src/wayland-client.c:1815
    swaywm#3 0x40f465 in swaynag_run ../swaynag/swaynag.c:390
    swaywm#4 0x407576 in main ../swaynag/main.c:123
    swaywm#5 0x7f5b58bb9412 in __libc_start_main ../csu/libc-start.c:308
    swaywm#6 0x404a3d in _start (/opt/wayland/bin/swaynag+0x404a3d)

0x612000000110 is located 208 bytes inside of 320-byte region [0x612000000040,0x612000000180)
freed by thread T0 here:
    #0 0x7f5b594ab480 in free (/lib64/libasan.so.5+0xef480)
    swaywm#1 0x40faff in swaynag_destroy ../swaynag/swaynag.c:454
    swaywm#2 0x40cbb4 in layer_surface_closed ../swaynag/swaynag.c:82
    swaywm#3 0x7f5b583e1acd in ffi_call_unix64 (/lib64/libffi.so.6+0x6acd)

previously allocated by thread T0 here:
    #0 0x7f5b594aba50 in __interceptor_calloc (/lib64/libasan.so.5+0xefa50)
    swaywm#1 0x7f5b58f0c902 in wl_display_connect_to_fd src/wayland-private.h:236

martinetd added a commit to martinetd/sway that referenced this issue Oct 7, 2018

swaynag: fix use-after-free in wl_display_dispatch
When destroying swaynag from within wl_display_dispatch, we cannot
disconnect the display as that will free the queue's event_list.
Free it after running the loop instead.

Fixes this use-after-free:
==7312==ERROR: AddressSanitizer: heap-use-after-free on address 0x612000000110 at pc 0x000000412a9f bp 0x7ffd4e811760 sp 0x7ffd4e811750
READ of size 8 at 0x612000000110 thread T0
    #0 0x412a9e in wl_list_empty ../common/list.c:206
    swaywm#1 0x7f5b58f0d42f in dispatch_queue src/wayland-client.c:1572
    swaywm#2 0x7f5b58f0d42f in wl_display_dispatch_queue_pending src/wayland-client.c:1815
    swaywm#3 0x40f465 in swaynag_run ../swaynag/swaynag.c:390
    swaywm#4 0x407576 in main ../swaynag/main.c:123
    swaywm#5 0x7f5b58bb9412 in __libc_start_main ../csu/libc-start.c:308
    swaywm#6 0x404a3d in _start (/opt/wayland/bin/swaynag+0x404a3d)

0x612000000110 is located 208 bytes inside of 320-byte region [0x612000000040,0x612000000180)
freed by thread T0 here:
    #0 0x7f5b594ab480 in free (/lib64/libasan.so.5+0xef480)
    swaywm#1 0x40faff in swaynag_destroy ../swaynag/swaynag.c:454
    swaywm#2 0x40cbb4 in layer_surface_closed ../swaynag/swaynag.c:82
    swaywm#3 0x7f5b583e1acd in ffi_call_unix64 (/lib64/libffi.so.6+0x6acd)

previously allocated by thread T0 here:
    #0 0x7f5b594aba50 in __interceptor_calloc (/lib64/libasan.so.5+0xefa50)
    swaywm#1 0x7f5b58f0c902 in wl_display_connect_to_fd src/wayland-private.h:236

(you need a wayland compiled with asan, my wl_list hack, or running
with valgrind to see this trace)
@SirCmpwn

This comment has been minimized.

Show comment
Hide comment
@SirCmpwn

SirCmpwn Oct 14, 2018

Member

We have now reached our compatability target with i3. With the exception of layout save/restore and features which only make sense on X11, all i3 features are supported.

Member

SirCmpwn commented Oct 14, 2018

We have now reached our compatability target with i3. With the exception of layout save/restore and features which only make sense on X11, all i3 features are supported.

@SirCmpwn SirCmpwn closed this Oct 14, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment