| Age | Commit message (Collapse) | Author |
|---|
|
programmatically
|
|
|
|
|
|
|
|
The existing support for the coretemp kernel driver only works with
Intel CPUs.
This commit extends support for temperature monitoring to AMD CPUs.
k10temp is a kernel driver for monitoring the temperature of AMD
processors. It supports everything from AMD's 10h (Opteron/Athlon)
family of processors to the latest 19h (Zen 3) family.
Reference: https://www.kernel.org/doc/html/latest/hwmon/k10temp.html
The meaning of the various temperatures made available has changed over
the years and only `Tctl` is available on processors prior to the 17h
family.
Labels for these temperatures are present but as Tctl and Tdie do not
contain a number I could not find a way to use these as
`checkedDataRetrieval` expects an integer label.
It is a PCI device and so an address needs to be supplied as part of the
configuration.
Example configuration:
`Run K10Temp "0000:00:18.3" ["--template", "T: <Tdie>C | <Tccd1>C"] 60`
|
|
|
|
While using xmobar to reproduce/fix a bug in xmonad I noticed that
xmobar doesn't react immediately to the signals to reposition or change
screen.
Apparently none of the Xlib functions called from `repositionWin` flush
the Xlib output buffer (XMoveResizeWindow is known to not flush,
although it's unfortunately not documented), so when compiled with the
threaded runtime that runs XNextEvent in a separate thread, the
reposition is sent to the X server only later when other stuff happens.
With all monitors set to refresh once a minute, this can take a looong
time.
(It's entirely possible this happens even without the threaded runtime,
I didn't test that, sorry.)
The fix is to call XSync at the end of `repositionWin`.
While at it, I spotted that drawInWin calls XSync with discard=true,
which seems like a mistake. We don't want to discard any events, do we?
(In practice, I'd expect the `eventer` thread to read all events even
before the drawing thread manages to discard them, so even if this
discarding XSync ever had any reason to be there, I don't think it does
anything meaningful these days. I may be wrong, though.)
|
|
Fix a link to an example.
|
|
This reverts commits c6669e26e1 (partially; changelog entry kept),
73e02934d6, 78efa5900a.
These commits were introduced as a workaround for a double UTF-8
encoding bug in xmonad-contrib which itself was meant to be a
fix/workaround for another issue. We have now identified the underlying
issue and fixed it right at the root, so this entire cascade of hacky
(and wrong) workarounds can be safely reverted. Thankfully, none of the
xmonad-contrib hacks made it into a release, so there's no backward
compat to worry about.
Should anyone be interested in the details,
https://github.com/xmonad/xmonad-contrib/commit/63e31ccd8d2865863778207b679f806941bf2788
provides a summary and links to all the related issues and PRs.
Related: https://github.com/jaor/xmobar/pull/482
Related: https://github.com/jaor/xmobar/issues/476
Related: https://github.com/xmonad/xmonad-contrib/commit/63e31ccd8d2865863778207b679f806941bf2788
Related: https://github.com/xmonad/xmonad-contrib/pull/471
Related: https://github.com/xmonad/xmonad-contrib/issues/377
|
|
|
|
hlint started failing recently:
src/Xmobar/X11/Text.hs:121:32: Error: Parse error: on input `-'
Found:
textExtents (Utf8 fs) s = do
let (_,rl) = wcTextExtents fs s
> ascent = fromIntegral $ - (rect_y rl)
descent = fromIntegral $ rect_height rl + fromIntegral (rect_y rl)
return (ascent, descent)
It's probably a change in the parser or something, didn't really look
into it, just changed it to something that's parsable.
|
|
Pixel intervals in _NET_WM_STRUT_PARTIAL are closed, not open [1], so
xmobar of width 1920 at x=0 needs to be encoded as ⟨0, 1919⟩, not ⟨0,
1920). The code already does this for Top/Bottom positioning, but Static
has been buggy for years.
[1]: https://specifications.freedesktop.org/wm-spec/1.5/ar01s05.html#idm46075117229424
Fixes: https://old.reddit.com/r/xmonad/comments/mynegr/xmobar_dual_monitor_bug/
Fixes: https://github.com/jaor/xmobar/issues/530
|
|
|
|
The cpp option `-DRTSOPTS` results in `RTSOPTS` being defined.
|
|
|
|
|
|
Exposing Common.Types and Common.Run is now redundant, but we could
break configurations out there, so i'm not sure if we should remove them.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The contributing.org file also contains information on how to write a
new monitor for xmobar.
The quick-start guide got reworked a bit to inline similar parts.
|
|
|
|
This also moves Date and DateZone to the monitors section (as they are
monitors themselves). A little bit of documentation was also
added/updated.
|
|
Mostly updating links and old (i.e. outdated) information
|
|
|
|
|
|
|
|
|
|
This plugin checks for new mail, provided that this mail is indexed by
notmuch. As mail that was tagged is moved from the new directory to
cur, the 'Mail' plugin (and its variants) won't work for such mail.
|
|
|
|
Also make indentation of shell code a little bit more regular.
|
|
|
|
Failed at least once in GitHub Actions:
predicate failed on: "Cpu: <fc=red>100</fc>% <fc=red>##########</fc>"
Also, there's no need to guard the Xmobar.Plugins.Monitors.CpuSpec
module with the with_alsa flag. (And it doesn't really work anyway,
hspec-discover doesn't care about what modules are declared in cabal, so
stack/ghc complains that "These modules are needed for compilation but
not listed in your .cabal file's other-modules:
Xmobar.Plugins.Monitors.AlsaSpec" and then fails to detect changes in
those modules.)
|
|
Introducing the throttling unfortunately has a negative side-effect: it
delays all stdin processing, including EOF detection, which can cause
confusion the previous commit tries to fix.
The only benefit of the throttling is to prevent 100% CPU usage when a
lot of garbage is provided on xmobar stdin. We still don't know where
that garbage comes from in https://github.com/jaor/xmobar/issues/438, or
rather why there's more than a handful of lines of such garbage. @psibi
has since fixed his setup to not produce that garbage, and no one else
ever reported such a problem, so it's probably safe to ignore it for
now.
Should anyone ever encounter that again, feel free to ping me, even in
the middle of the night, to help debug this.
Fixes: 7759df11f746 ("StdinReader: Improve exception handling")
Fixes: b7a3d6745817 ("Avoid busy looping by not catching all exceptions")
|
|
This corrects a misleading comment "EOF check is necessary for certain
systems" which was added without complete understanding of the root
cause of #442. That issue was in fact caused by old xmobars not being
terminated on early EOF, and is thus necessary on _all_ systems that
rely on EOF to terminate old xmobar before starting a new one. (To
trigger the bug, one additionally needs to close the xmobar pipe before
sending any input to it, which is unusual, but incorrectly configured
xmonad might trigger that.)
Furthermore, this fixes another execution path that could lead to xmobar
not being terminated on EOF:
`echo -e '\xff' | xmobar -c '[Run StdinReader]' -t '%StdinReader%'`
would terminate the StdinReader thread upon catching the "invalid
argument (invalid byte sequence)" so there'd be no thread to detect the
subsequent EOF and xmobar would get stuck.
Additionally, I believe that terminating either the thread or the entire
xmobar upon receiving a single miscoded byte isn't desirable, as this
might be an intermittent issue and another input line can be perfectly
okay. Therefore I suggest that the original issue @psibi was trying to
fix by b7a3d6745817 is worked around by introducing a throttling delay
instead of terminating the thread, as I assume that exceptions other
than async and EOF are recoverable.
Fixes: b7a3d6745817 ("Avoid busy looping by not catching all exceptions")
Fixes: 68ac4d3ae6f3 ("Update stderr and the bar on receiving exception")
Fixes: ed0663aac942 ("Add EOF check before getLine operation from stdin")
Fixes: https://github.com/jaor/xmobar/issues/442
Related: https://github.com/jaor/xmobar/pull/439
Related: https://github.com/jaor/xmobar/pull/448
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This fixes the following crash that happens with the default xmobar
configuration (using HOME=/ makes xmobar ignore ~/.xmobarrc):
$ echo "<fn=1>x</fn>" | HOME=/ xmobar
xmobar: Prelude.!!: index too large
Commit 3e9e1cb9d300 ("Fix crashes/busy looping happening via index")
meant to fix this but apparently it only fixed indexing of fontlist, not
voffs, so the crash was still there.
Fixes: https://github.com/jaor/xmobar/issues/504
|
|
The readme says additional fonts are centered vertically if a
corresponding offset isn't specified in `textOffsets`, but this didn't
happen as we used the first font's metrics for centering of all fonts
instead.
Fixes: a2365debfaba ("New configuration parameter `textOffsets` (fixes #311)")
|
|
|
