profile
viewpoint
Anton Älgmyr algmyr Zürich Competitive programming. Terminal as a natural habitat. Fan of FOSS in general and Linuxy stuff in particular.

cheran-senthil/TLE 227

🤖 Discord Bot for Competitive Programming

algmyr/e-maxx-eng-book 34

Book version of e-maxx-eng

algmyr/decenc 2

Tools for handling Hacknet's DEC_ENC file format

algmyr/e-maxx-eng 1

Translation of http://e-maxx.ru into English

algmyr/2017 0

Templates for the Busy bus | coding competition

algmyr/alttp_vt_randomizer 0

ALttP VT Randomizer and API

algmyr/chalmers-card-balance 0

Public API for checking account balance of Chalmers Student Union cards

algmyr/clippy.sh 0

Simple clipboard helper written in bash with QOL features

issue commentchorankates/h4ck

Hacking process of LaMetric time

Looking at the thing that actually does the firmware update /lametric/system/services/com.lametric.lametricdaemon/daemon I actually see nothing that verifies the signature file. What I see is that thing running /etc/validate_fw.sh which only checks the MD5 hash, which you could just update after updating the squashfs image. This is a dumb question, but have people tried just updating the md5sum after modification? It's likely that I'm missing the place actually doing the signature check, but I have to ask.

arandomliz

comment created time in 8 days

push eventbjorn-martinsson/MaxCutInapproximability

Anton Älgmyr

commit sha 2ee9211cfda7e6241762c27b969d9843eeab7b94

Remove using namespace lemon, and fix compile error in assert

view details

push time in a month

push eventbjorn-martinsson/MaxCutInapproximability

Anton Älgmyr

commit sha 2db30956544fb828099cd9b26282e06df8805131

Make headers a tad more sane

view details

push time in a month

pull request commenti3/i3

Fix focus issue when moving windows across outputs

I guess I didn't end up mentioning that anywhere. The behavior is different when you run i3-msg move right and when you run it as a keybind. With the keybind you get focus one to the right of the intended window (i.e. the issue in this PR). With the command you seem to get focus on the rightmost thing on the original output (or the container at the root if you move the last window). All in all it's pretty weird.

orestisfl

comment created time in a month

pull request commenti3/i3

Fix focus issue when moving windows across output boundary

Can confirm that the mouse warping is causing the underlying issue, commenting out the mouse warp at https://github.com/i3/i3/blob/ab389e1d760585e758f343221da7758f7bc2c949/src/workspace.c#L537-L539 makes the issue go away.

algmyr

comment created time in a month

issue commenti3/i3

Focus does not follow window with directional move when focus_follows_mouse is enabled

Made #4596 to workaround this particular issue, but thinking about the whole situation there seems to be a much more fundamental issue with focus_follows_mouse and i3 moving the mouse around itself. See the PR for some more thoughts.

JonnyHaystack

comment created time in a month

PR opened i3/i3

Fix focus issue when moving windows across output boundary

Focusing the container before doing the workspace switching dance seems to do the trick to fix #3518. Running locally the tests seem ok with the change.

I don't exactly know why the existing code doesn't work, setting focus to the specific container seems like it should work since is explicitly calls out to focus a specific container. If I had to guess it's a weird race condition like sequence, something like

  • i3 moves window
  • i3 makes sure the switch workspace event is changed by switching back and forth
  • this workspace switch to another output triggers a mouse move to the currently selected container on the other output
  • i3 focuses the new container
  • the mouse move from earlier (with focus_follows_mouse) focuses the container under the cursor, which is the one that had focus before

I'm able to reproduce similar issues when focusing. Scenario: I'm at my rightmost container in my left output, right output has a vertical split. Doing the keybinds for move right and move down in quick succession focuses the bottom container for a brief moment before jumping back to the container that the mouse jumped to. This would support the hypothesis of this being a race condition between i3 and Xorg.

If the above is the case this is just a hack that makes the behavior non-damaging for this particular case. The proper fix would be to not have the focus follows mouse happen in this case where i3 itself is the one moving the mouse (to a container that is focused already).

+1 -1

0 comment

1 changed file

pr created time in a month

push eventalgmyr/i3

Anton Älgmyr

commit sha d0b8ee2dcace1a71cbc3a0b29be382ad86204749

Fix focus issue when moving windows across output boundary

view details

push time in a month

fork algmyr/i3

A tiling window manager

https://i3wm.org/

fork in a month

issue commenti3/i3

Focus does not follow window with directional move when focus_follows_mouse is enabled

Played around a bit and focusing the correct container before doing the workspace back and forth to get the correct events triggered seems to do the right thing superficially. The correct container is focused on the other side, and the workspace indicator is updated which is what the workspace switching is intending to do.

         con_focus(con);
         focused = old_ws; 
         workspace_show(ws); 

@orestisfl considering you were the one to commit the fix for this years back, do you happen to have any idea if reversing the order of operations here would break anything?

JonnyHaystack

comment created time in a month

issue commenti3/i3

Focus does not follow window with directional move when focus_follows_mouse is enabled

I drilled down a bit and it seems this part is what triggers the issue https://github.com/i3/i3/blob/ab389e1d760585e758f343221da7758f7bc2c949/src/move.c#L227-L234

In particular removing focused = old_ws; makes the issue go away (and probably breaks other stuff, like the test in question).

JonnyHaystack

comment created time in a month

issue commenti3/i3

Multiple monitors breaking after long time disconnect

I think I had this (or something similar) happen recently. A monitor had been disconnected for several days, reconnecting it froze everything graphical. I tried running xrandr over ssh and it would just hang and do nothing. Trying startx after force killing i3 and Xorg went into a similarly bad state (or I didn't wait long enough). Soft reboot hanged as well, had to power cycle to get things back to a stable state. Naively speaking this feels like an X issue, but I don't think I have any logs to confirm/deny that.

gczgcz2015

comment created time in 2 months

PR opened WerWolv/ImHex

Fix crash on pattern load

Fixes #318

+3 -1

0 comment

1 changed file

pr created time in 2 months

push eventalgmyr/ImHex

Anton Älgmyr

commit sha b687a8a19f55615e43e7cf318903cbc9d50f8ad4

Fix crash on pattern load

view details

push time in 2 months

fork algmyr/ImHex

A Hex Editor for Reverse Engineers, Programmers and people who value their retinas when working at 3 AM.

https://werwolv.net

fork in 2 months

issue openedWerWolv/ImHex

[Bug] Imhex crashes on pattern load because of non-existing directories

Operating System

Linux

What's the issue you encountered?

This doesn't check whether the path exists before trying to recurse into it. If the path doesn't exist an exception is thrown. https://github.com/WerWolv/ImHex/blob/2dc1886ee97a3264d9eeb632bfc2d269eb1a76d8/source/views/view_pattern_editor.cpp#L193-L195

How can the issue be reproduced?

Try loading patterns through File > Load pattern.... On my machine it first looks at /usr/bin/patterns (for some reason) and tries to go into it. This directory doesn't exist and an unhandled exception is thrown. Creating the directory makes it go on to another path /usr/local/share/imhex/patterns and crashes on that.

Example error:

terminate called after throwing an instance of 'std::filesystem::__cxx11::filesystem_error'
  what():  filesystem error: recursive directory iterator cannot open directory: No such file or directory [/usr/bin/patterns]

At this point I need to kill -9 to get rid of the frozen program.

ImHex Version

1.10.1

Additional context?

Arch Linux, using the non-git version of imhex with imhex-patterns-git. Though this shouldn't be relevant to this issue.

created time in 2 months

more