| Age | Commit message (Collapse) | Author |
|---|
|
We can assume (vwm->focused_desktop != NULL), the initial desktop
is created early in startup and the last one can't be destroyed.
|
|
It's far too obnoxious to use without this enabled.
Some spurious cleanups in the surrounding code landed here as well.
|
|
No functional changes here.
|
|
|
|
I had assumed pread wouldn't work on /proc files and that lseek to the
start was the only safe form of seeking, but this seems to be working
acceptably well even with buffer sizes of 2 requiring many sequential
reads per sample.
The lseek syscalls aren't free and it's nice to omit them entirely,
and we're essentially being sequential in our pread() use, and always
use a buffer that is large enough to fit everything in the first read
anyways.
|
|
The vmon->buf[_bis] buffers are nice to shrink to absurdly small
sizes for testing changes, but we can't do that when they're reused
for path construction.
Just use local on-stack buffers for constructing paths, and now things
continue to function just slower with vmon->buf[8].
|
|
This trivial change eliminates the final EOF realization read() syscall on
every /proc file consumed for every process on every sample, which adds up.
|
|
I think I've developed a force of habit typing `static inline` after
the ray tracer in rototiller.
|
|
Bring libvmon code inline with the direction vwm has headed in terms
of coding style. Entirely mechanical changes with one exception
replacing a free()/=NULL idiom with try_free().
|
|
vmon exposes the monitoring overlays of vwm through a standalone
commandline utility by creating dedicated window for presenting the
overlay.
At this time a single preexisting PID may be specified, forming the root of
a recursively monitored heirarchy. Alternatively, a command may specified
which vmon will then fork and execute on your behalf, automatically
monitoring the child and its descendants for you, in a style similar to
strace.
Examples:
Monitor a linux kernel build in fullscreen mode, note the --:
`vmon --fullscreen -- make -C /usr/src/linux -j8`
Monitor the entire system:
`vmon --fullscreen --pid 1`
For convenience, omitting --pid and a command to run assumes PID 1:
`vmon --fullscreen` is analogous to `vmon --fullscreen --pid 1`
Monitor a linux kernel build fullscreen at 50Hz:
`vmon --fullscreen --hertz 50 -- make -C /usr/src/linux -j8`
Do the same thing but don't exit when the make completes:
`vmon --linger --fullscreen --hertz 50 -- make -C /usr/src/linux -j8`
Help is provided via `vmon --help`, where you'll find all flags described
with their short and long forms.
Some important TODO items include:
- Support for specifying multiple top-level processes
- Support for mixing --pid and running a command
(useful for watching specific system processes while you're running
something specific)
- Support for scrolling within the window. The overlays in general need
to evolve a bit to better support the vmon use case. In vwm there
wasn't any intention of accomodating the entire space if it exceeded
what was naturally available in the existing window's dimensions.
That makes sense for vwm, but vmon not so much.
You can achieve the same thing more or less by resizing the window to be
larger than the screen (easy to do in vwm using a combination of
Mod1-Right-Click to resize, then Mod1-Left-Click to drag the window,
repeatedly. Then just Mod1-Left-Click to grab the window and "scroll"
it by moving the desired part on-screen, repeatedly. Cumbersome, but
works fine in a pinch. Not all window managers can do this though...
Of course it would be less costly to only render what's visible, like a
scrollable window would achieve. This is probably the top priority
TODO.
- Support for monitoring of memory use, files, per-process IO activity.
libvmon supports substantially more than is being visualized currently.
- Support for changing the font.
|
|
In vwm it was only necessary to relatively increase/decrease the sample
rate.
With vmon being primarily a cli tool, explicit setting of the rate is
desirable. This commit reworks things a little de-specializing the zero
value of overlays->sampling_interval, while switching this to instead of
being an index into the intervals table simply contain the float interval
itself. The math.h INFINITY macro becomes the new paused/zero value, and
simply gets an entry of its own in the intervals table as the lowest one.
|
|
In vwm we were always doing a transparent overlay to preserve underlying
window visibility. With vmon this is undesirable and we just want to
copy the currently cached composited contents to the window, which is
also substantially less costly to perform.
Parameterize the operation so vwm and vmon can specify what's appropriate.
|
|
I'm no longer fond of combining one-line conditional statements on
the same line as their conditional expression.
|
|
- Move vmon_proc_t under vwm_overlay_t.
- Privatize vwm_overlay_t.
- Update xwindow.c to dynamically create and destroy overlays.
- Cease supplying vwm_t to vwm_overlays_create(), now just
pass in the bare vwm_xserver_t.
- Update all vwm_overlay_* functions to operate on vwm_overlays_t and
vwm_overlay_t. Only vwm_overlays_create() receives the xserver,
which it then embeds within the returned vwm_overlay_t.
- Eliminate _xwin_ flavors of overlay functions, largely mechanical
rename eliminating the _xwin_ from the names during the previous
pass of switching from vwm_t & vwm_xwindow_t to vwm_overlays_t &
vwm_overlay_t parameters.
- Change vwm_overlay_compose() to store damage in supplied pointer,
the caller is expected to make use of the damage information now
because the overlay code doesn't know about the window its coordinate
space.
|
|
Eliminate some initialization cruft.
|
|
|
|
|
|
Introduce vwm_overlays_t and create/destroy functions, use in vwm_startup()
and vwm_shutdown(). Supply to methods operating on the global overlays
state vwm_overlays_update(), vwm_overlays_rate_increase(),
vwm_overlays_rate_decrease().
This is a fairly minimal adoption of these changes with vwm_t still being
supplyed to the overlay functions.
A future commit will further cleanup the interactions and cease all
knowledge of vwm_t in overlays.c, but for now everything overlay-oriented
still accesses the overlays_t instance via vwm_t. Instead of supplying the
vwm_t to vwm_overlays_create() the bare vwm_xserver_t will be supplied, as
this is the future shared component across vmon and vwm (in addition to
overlays).
|
|
In preparation for vwm_overlays_* encapsulation of overlay global state
and general cleanup therein.
|
|
We need to eventually plumb an vwm_overlays_t reference back to sample_cb,
for now we'll just obviate the need for the vwm_ptr global by plumbing the
vwm_t through.
|
|
|
|
In preparation for monitoring overlays being shared across vwm and vmon,
adding a common xserver abstraction for both to use and overlay to depend
on.
|
|
|
|
In preparation for separating out the monitoring overlay code
from being vwm-coupled, moving these into an independent header
since they'll be used throughout.
|
|
If walking ancestors never entered the loop, bar_y isn't set.
Set the bar_y once per row, and independent of ancestors. This
is obviously more correct and fixes a situation where the siblings
have children but there are no ancestors (siblings under the root).
Surprisingly this isn't generally observed in vwm, but was noticed
in vmon development.
|
|
Tidy up vwm exit handling and stop leaking an X Region on every clean vwm_composite_paint_all().
If you noticed very long-running vwm instances hogging memory like a web browser, this is the culprit, vwm doesn't typically need much memory.
|
|
When vwm_composite_paint_all() short-circuited, occluded wasn't destroyed.
Defer the occluded region create to its time of need, which is after the
short-circuit, and followed immediately by its destruction.
|
|
This moves the console teardown back to vwm.c, trivial cleanup.
|
|
it's not being used for anything as of now.
|
|
|
|
|
|
readdir_r() has been deprecated in glibc
|
|
|
|
Sometimes `mplayer -fs` would result in an unmanaged window. It seems to be
due to an unexpected ordering of events on the window:
create notify 0x1000001
creating 0x1000001
map request 0x1000001
managing 0x1000001
configure request 0x1000001
unmap notify 0x1000001 from configure 0
unmanaging 0x1000001
configure notify 0x1000001
map notify 0x1000001 <----- this happens after the window has been unmanaged!
configure notify 0x1000001
configure request 0x1000001
configure request 0x1000001
configure request 0x1000001
configure request 0x1000001
configure notify 0x1000001
So in handling MapNotify, if the window is !managed && !override_redirect,
manage it.
This is confirmed to fix the occasionally unmanaged `mplayer -fs` window.
|
|
This was a known bug, there's a TODO sitting right there noting it.
The items array was sized very large so it never triggered and was
forgotten about.
Running `make tags` in the linux kernel source steps on it though,
because it constructs a massive argv.
This just adds a bounds check so no crash occurs in argv2xtext().
I don't see the point of allocating memory for this as the TODO's
suggested, since any such argv is unlikely to fit in the overlay
anyways.
Also shrunk the max from 1024 to 512, which is still quite large.
|
|
key: decrement key_is_grabbed release of multi-Alt
|
|
Upon releasing all keys concluding a grab the counter gets reset so this isn't
generally observed as being a problem.
Sometimes the second Alt is released by itself, restoring the origin, and the
original grabbing single Alt persists for subsequent window management
operations. It's in this situation when the bug manifests. If the final Alt
release occurred with a focused window/desktop differing from the origin, on
the final Alt release an unexpected restore to the origin occurred.
Usually this goes unnoticed, because typically the lone Alt release occurs
immediately following the other one, and the second restore to origin happens
to be idempotent.
|
|
House cleaning
|
|
If vmon hasn't seen any heirarchical changes, and we aren't forcing a redraw,
and the process information being shown isn't changed, don't bother
re-rendering the same thing the overlay already contains.
This can be further improved, like if only wchan changed and nothing else, only
redraw the wchan column for the relevant row. It gets tricky quickly though,
because a new wchan could be wider than the column currently permits for
example, then we'd need to go render all the rows to the new wchan column
width...
It's simpler to just redraw it all if anything has changed, and this stuff
doesn't generally change that frequently in practice so it's pretty effective
as-is.
|
|
The samplers may set these, but we need to clear them on every vmon_sample().
|
|
|
|
Set on window resize, clear on draw_overlay() return.
Used in combination with sample_interval check to gate HZ redraw.
Will be used to gate redraw of process monitors heirarchy as well,
in a subsequent commit.
|
|
Also moved vertical graph bars drawing to helper function
|
|
We currently only use the width, and XTextExtents does substantially more crap
per character in Xorg's xlib. XTextWidth is not just a wrapper around it, it's
a specialized subset implementation.
|
|
Trying this out now that there's a pile of files... sigh.
Note this spuriously duplicates list.h @ src/libvmon/list.h, the old Makefile
shared list.h between vwm and libvmon, but I'm letting them have their own
instances with autotools. Libvmon was always an independent project I just
pulled in for vwm's use, and will likely continue to be developed independent
of vwm with occasional syncs.
|
|
Long overdue house cleaning.
The addition of compositing/monitoring overlays in vwm3 pushed vwm well past
what is a reasonable size for a simple thousand line file. This is a first
step towards restoring sanity in the code, but no behavioral differences are
intended, this is mostly just shuffling around and organizing code.
I expect some performance regressions initially, follow-on commits will make
more improvements to that end as the dust settles.
|
|
I've warmed up to space after control flow keywords
|
|
Approximately:
s/if(/if (/g
s/switch(/switch (/g
s/do(/do (/g
s/while(/while (/g
s/for(/for (/g
Macro use continues to be spaceless, even when used as control flow primitives
(i.e. list_for_each()), as do function calls.
|
|
Fix handling of non-visible focus switches
|
|
It's inappropriate to assume the window being focused is in the visible
context. This caused the input focus to spuriously vanish if a window on
another desktop went away causing the next one, also invisible, to get focused.
I'm surprised how long I went without ever noticing this bug! My workflow
basically never has windows vanishing that aren't in the focused context.
|
