On Fri, Nov 19, 2021 at 08:18:45AM +0100, Jan Stary wrote:
> On Nov 19 00:01:04, stef...@sdaoden.eu wrote:
> > Jan Stary wrote in
> > <yzam+qt6hadpj...@www.stare.cz>:
> > |On Nov 18 20:13:03, h...@stare.cz wrote:
> > |> On Nov 16 21:33:31, hen...@camandro.org wrote:
> > |>> I've tried to setup a line like:
> > |>> bind-key XF86MonBrightnessDown "<cmd>"
> > |>> in my .cwmrc and the result was that no key event was sent to my \
> > |>> windows.
> > |>
> > |> Please excuse my X ignorance, but shouldn't XF86MonBrightnessDown
> > |> be catched by the X server (to take the brightness down),
> > |> as opposed to passing it on to cwm?
> > |
> > |Or even sooner? For example, xev(1) does not report anything
> > |when I press [Fn]+[LightsDown] on my Thinkpad T400 running cwm.
> >
> > Just tell him that his keyboard does not generate the event,
>
> I am not sure what you mean by that,
> but pressing those keys does dim my monitor.
>
> That makes me thinks the event is "catched"
> ("consumed", "processed" - I don't know the terminology)
> before it reaches the xev application (running in cwm).
>
> And that is (I speculate) why the OP also doesn't see the key processed
> in his window manager - because it never even reaches the window manager.
My problem isn't about XF86MonBrightnessDown not being processed (I don't
really care about that). My patch is about a 'bind-key' configuration
that makes cwm unusable because *no* key is ever sent to a window (i.e. I
can't type!). And that's what my patch tries to fix. If
XF86MonBrightnessDown never happens or if it's handled by BIOS directly,
that's just an annoying fact that I can live with.
Cheers,
--
Luís
