cwm: add key bindings to cycle windows of same window class
Hi folks,
Here's a patch I've been dragging around for years now that allows cwm
to cycle through windows of the same window class as the current one.
Man page parts included, and a default key binding to M-grave,
respectively Alt-Tilde, like other window managers have as well.
Who likes it?
Cheers,
Simon
P.S.: As I'm still inactive, please feel free to take the commit.
Index: calmwm.h
===
RCS file: /cvs/xenocara/app/cwm/calmwm.h,v
retrieving revision 1.378
diff -u -p -r1.378 calmwm.h
--- calmwm.h26 Feb 2022 15:19:18 - 1.378
+++ calmwm.h14 Jul 2023 20:12:40 -
@@ -67,6 +67,7 @@
#define CWM_CYCLE_FORWARD 0x0001
#define CWM_CYCLE_REVERSE 0x0002
#define CWM_CYCLE_INGROUP 0x0004
+#define CWM_CYCLE_INCLASS 0x0008
enum cwm_status {
CWM_QUIT,
Index: conf.c
===
RCS file: /cvs/xenocara/app/cwm/conf.c,v
retrieving revision 1.255
diff -u -p -r1.255 conf.c
--- conf.c 26 Feb 2022 15:19:18 - 1.255
+++ conf.c 14 Jul 2023 20:12:40 -
@@ -136,6 +136,10 @@ static const struct {
(CWM_CYCLE_FORWARD | CWM_CYCLE_INGROUP)) },
{ FUNC_SC(window-rcycle-ingroup, client_cycle,
(CWM_CYCLE_REVERSE | CWM_CYCLE_INGROUP)) },
+ { FUNC_SC(window-cycle-inclass, client_cycle,
+ (CWM_CYCLE_FORWARD | CWM_CYCLE_INCLASS)) },
+ { FUNC_SC(window-rcycle-inclass, client_cycle,
+ (CWM_CYCLE_REVERSE | CWM_CYCLE_INCLASS)) },
{ FUNC_SC(group-cycle, group_cycle, (CWM_CYCLE_FORWARD)) },
{ FUNC_SC(group-rcycle, group_cycle, (CWM_CYCLE_REVERSE)) },
@@ -220,6 +224,8 @@ static const struct {
{ "C-slash","menu-cmd" },
{ "M-Tab", "window-cycle" },
{ "MS-Tab", "window-rcycle" },
+ { "M-grave","window-cycle-inclass" },
+ { "MS-grave", "window-rcycle-inclass" },
{ "CM-n", "window-menu-label" },
{ "CM-x", "window-close" },
{ "CM-a", "group-toggle-all" },
Index: cwm.1
===
RCS file: /cvs/xenocara/app/cwm/cwm.1,v
retrieving revision 1.65
diff -u -p -r1.65 cwm.1
--- cwm.1 9 Jul 2019 21:38:44 - 1.65
+++ cwm.1 14 Jul 2023 20:12:40 -
@@ -102,6 +102,10 @@ Label current window.
Cycle through currently visible windows.
.It Ic MS-Tab
Reverse cycle through currently visible windows.
+.It Ic M-grave
+Cycle through currently visible windows of the same window class.
+.It Ic MS-grave
+Reverse cycle through currently visible windows of the same window class.
.It Ic CM-x
Close current window.
.It Ic CM-[n]
Index: cwmrc.5
===
RCS file: /cvs/xenocara/app/cwm/cwmrc.5,v
retrieving revision 1.77
diff -u -p -r1.77 cwmrc.5
--- cwmrc.5 27 Jan 2022 18:45:10 - 1.77
+++ cwmrc.5 14 Jul 2023 20:12:40 -
@@ -295,6 +295,10 @@ Reverse cycle through windows.
Forward cycle through windows in current group.
.It window-rcycle-ingroup
Reverse cycle through windows in current group.
+.It window-cycle-inclass
+Forward cycle through windows of the current window class.
+.It window-rcycle-inclass
+Reverse cycle through windows of the current window class.
.It window-close
Close current window.
.It window-hide
Index: kbfunc.c
===
RCS file: /cvs/xenocara/app/cwm/kbfunc.c,v
retrieving revision 1.173
diff -u -p -r1.173 kbfunc.c
--- kbfunc.c27 Feb 2022 14:59:55 - 1.173
+++ kbfunc.c14 Jul 2023 20:12:40 -
@@ -430,7 +430,9 @@ kbfunc_client_cycle(void *ctx, struct ca
/* Only cycle visible and non-ignored windows. */
if ((newcc->flags & (CLIENT_SKIP_CYCLE)) ||
((flags & CWM_CYCLE_INGROUP) &&
- (newcc->gc != oldcc->gc)))
+ (newcc->gc != oldcc->gc)) ||
+ ((flags & CWM_CYCLE_INCLASS) &&
+ strcmp(newcc->res_class, oldcc->res_class) != 0))
again = 1;
/* Is oldcc the only non-hidden window? */
Re: [Diff] Keyboard backlight support for late powerbooks, plus keybindings
Thank you very much for testing. > the diff looks good to me except for maybe the numlock bit in > hidkbd I agree, that was part of my incipient attempt to fix numlock on these laptops as well, please drop it from this diff, it is unrelated. > One thing I am never quite sure about is the keycode to internal > key translation Same here, I just picked incrementally, I hope someone could shed a bit more light on this
Re: [Diff] Keyboard backlight support for late powerbooks, plus keybindings
On Fri, Jul 14, 2023 at 05:53:41PM +, jon@elytron.openbsd.amsterdam wrote:
> Hello everyone. After a tobhe@'s recent patch [1] to add suspend
> keysyms for other mac laptops, and a brief consultation with him,
> I am reposting an updated version of my keyboard backlight
> patch [2], which you can find below:
>
> [1] https://marc.info/?l=openbsd-tech=168884670208963=2
>
> [2] https://marc.info/?l=openbsd-tech=167755750511636=2
Hi,
the diff looks good to me except for maybe the numlock bit in hidkbd
which seems unrelated to the rest of the changes, but we can drop that
before committing.
One thing I am never quite sure about is the keycode to internal key
translation,
I am assuming you just picked 234 - 236 incrementally. Maybe miod@ (cc) knows if
there are better ones to use here.
I have also tested it and verified it works on my PowerBook G4.
ok anyone?
>
> Index: arch/macppc/dev/adb.c
> ===
> RCS file: /cvs/src/sys/arch/macppc/dev/adb.c,v
> retrieving revision 1.50
> diff -u -p -r1.50 adb.c
> --- arch/macppc/dev/adb.c 11 Apr 2023 00:45:07 - 1.50
> +++ arch/macppc/dev/adb.c 13 Jul 2023 21:17:17 -
> @@ -102,6 +102,8 @@
> #include
> #include
>
> +#include
> +
> #include "apm.h"
>
> #define printf_intr printf
> @@ -242,6 +244,12 @@ void setsoftadb(void);
> int adb_intr(void *arg);
> void adb_cuda_autopoll(void);
> void adb_cuda_fileserver_mode(void);
> +uint8_t pmu_backlight; /* keyboard backlight value */
> +int pmu_get_backlight(struct wskbd_backlight *);
> +int pmu_set_backlight(struct wskbd_backlight *);
> +extern int (*wskbd_get_backlight)(struct wskbd_backlight *);
> +extern int (*wskbd_set_backlight)(struct wskbd_backlight *);
> +
>
> #ifndef SMALL_KERNEL
> void adb_shutdown(void *);
> @@ -1730,8 +1738,11 @@ adbattach(struct device *parent, struct
>
> if (adbHardware == ADB_HW_CUDA)
> adb_cuda_fileserver_mode();
> - if (adbHardware == ADB_HW_PMU)
> + if (adbHardware == ADB_HW_PMU) {
> + wskbd_get_backlight = pmu_get_backlight;
> + wskbd_set_backlight = pmu_set_backlight;
> pmu_fileserver_mode(1);
> + }
>
> /*
>* XXX If the machine doesn't have an ADB bus (PowerBook5,6+)
> @@ -1757,4 +1768,20 @@ adbattach(struct device *parent, struct
> if (adbHardware == ADB_HW_CUDA)
> adb_cuda_autopoll();
> adb_polling = 0;
> +}
> +
> +int
> +pmu_get_backlight(struct wskbd_backlight *kbl)
> +{
> + kbl->min = 0;
> + kbl->max = 0xff;
> + kbl->curval = pmu_backlight;
> + return 0;
> +}
> +
> +int
> +pmu_set_backlight(struct wskbd_backlight *kbl)
> +{
> + pmu_backlight = kbl->curval;
> + return pmu_set_kbl(pmu_backlight);
> }
> Index: arch/macppc/dev/pm_direct.c
> ===
> RCS file: /cvs/src/sys/arch/macppc/dev/pm_direct.c,v
> retrieving revision 1.34
> diff -u -p -r1.34 pm_direct.c
> --- arch/macppc/dev/pm_direct.c 28 Dec 2022 07:40:23 - 1.34
> +++ arch/macppc/dev/pm_direct.c 13 Jul 2023 21:17:24 -
> @@ -853,3 +853,22 @@ pmu_fileserver_mode(int on)
> }
> pmgrop();
> }
> +
> +int
> +pmu_set_kbl(unsigned int level)
> +{
> + if (level > 0xff)
> + return (EINVAL);
> +
> + PMData p;
> +
> + p.command = 0x4F;
> + p.num_data = 3;
> + p.s_buf = p.r_buf = p.data;
> + p.data[0] = 0;
> + p.data[1] = 0;
> + p.data[2] = level;
> + pmgrop();
> + return (0);
> +}
> +
> Index: arch/macppc/dev/pm_direct.h
> ===
> RCS file: /cvs/src/sys/arch/macppc/dev/pm_direct.h,v
> retrieving revision 1.15
> diff -u -p -r1.15 pm_direct.h
> --- arch/macppc/dev/pm_direct.h 21 Oct 2022 22:42:36 - 1.15
> +++ arch/macppc/dev/pm_direct.h 13 Jul 2023 21:17:24 -
> @@ -67,6 +67,7 @@ struct pmu_battery_info
> };
>
> int pm_battery_info(int, struct pmu_battery_info *);
> +int pmu_set_kbl(unsigned int);
>
> void pm_eject_pcmcia(int);
> void pmu_fileserver_mode(int);
> Index: dev/hid/hidkbd.c
> ===
> RCS file: /cvs/src/sys/dev/hid/hidkbd.c,v
> retrieving revision 1.9
> diff -u -p -r1.9 hidkbd.c
> --- dev/hid/hidkbd.c 9 Jul 2023 08:02:13 - 1.9
> +++ dev/hid/hidkbd.c 13 Jul 2023 21:17:42 -
> @@ -143,6 +143,10 @@ static const struct hidkbd_translation a
> { 60, 127 },/* F3 -> audio mute */
> { 61, 129 },/* F4 -> audio lower */
> { 62, 128 },/* F5 -> audio raise */
> + { 63, 83 }, /* F6 -> num lock */
> + { 65, 234 },/* F8 -> backlight toggle*/
> + { 66, 236 },/* F9 -> backlight lower */
> + { 67, 235 },/* F10 -> backlight raise*/
> #else
> { 63, 102 },/* F6 -> sleep */
> { 67, 127 },/* F10
[Diff] Keyboard backlight support for late powerbooks, plus keybindings
Hello everyone. After a tobhe@'s recent patch [1] to add suspend
keysyms for other mac laptops, and a brief consultation with him,
I am reposting an updated version of my keyboard backlight
patch [2], which you can find below:
[1] https://marc.info/?l=openbsd-tech=168884670208963=2
[2] https://marc.info/?l=openbsd-tech=167755750511636=2
Index: arch/macppc/dev/adb.c
===
RCS file: /cvs/src/sys/arch/macppc/dev/adb.c,v
retrieving revision 1.50
diff -u -p -r1.50 adb.c
--- arch/macppc/dev/adb.c 11 Apr 2023 00:45:07 - 1.50
+++ arch/macppc/dev/adb.c 13 Jul 2023 21:17:17 -
@@ -102,6 +102,8 @@
#include
#include
+#include
+
#include "apm.h"
#define printf_intr printf
@@ -242,6 +244,12 @@ void setsoftadb(void);
intadb_intr(void *arg);
void adb_cuda_autopoll(void);
void adb_cuda_fileserver_mode(void);
+uint8_t pmu_backlight; /* keyboard backlight value */
+intpmu_get_backlight(struct wskbd_backlight *);
+intpmu_set_backlight(struct wskbd_backlight *);
+extern int (*wskbd_get_backlight)(struct wskbd_backlight *);
+extern int (*wskbd_set_backlight)(struct wskbd_backlight *);
+
#ifndef SMALL_KERNEL
void adb_shutdown(void *);
@@ -1730,8 +1738,11 @@ adbattach(struct device *parent, struct
if (adbHardware == ADB_HW_CUDA)
adb_cuda_fileserver_mode();
- if (adbHardware == ADB_HW_PMU)
+ if (adbHardware == ADB_HW_PMU) {
+ wskbd_get_backlight = pmu_get_backlight;
+ wskbd_set_backlight = pmu_set_backlight;
pmu_fileserver_mode(1);
+ }
/*
* XXX If the machine doesn't have an ADB bus (PowerBook5,6+)
@@ -1757,4 +1768,20 @@ adbattach(struct device *parent, struct
if (adbHardware == ADB_HW_CUDA)
adb_cuda_autopoll();
adb_polling = 0;
+}
+
+int
+pmu_get_backlight(struct wskbd_backlight *kbl)
+{
+ kbl->min = 0;
+ kbl->max = 0xff;
+ kbl->curval = pmu_backlight;
+ return 0;
+}
+
+int
+pmu_set_backlight(struct wskbd_backlight *kbl)
+{
+ pmu_backlight = kbl->curval;
+ return pmu_set_kbl(pmu_backlight);
}
Index: arch/macppc/dev/pm_direct.c
===
RCS file: /cvs/src/sys/arch/macppc/dev/pm_direct.c,v
retrieving revision 1.34
diff -u -p -r1.34 pm_direct.c
--- arch/macppc/dev/pm_direct.c 28 Dec 2022 07:40:23 - 1.34
+++ arch/macppc/dev/pm_direct.c 13 Jul 2023 21:17:24 -
@@ -853,3 +853,22 @@ pmu_fileserver_mode(int on)
}
pmgrop();
}
+
+int
+pmu_set_kbl(unsigned int level)
+{
+ if (level > 0xff)
+ return (EINVAL);
+
+ PMData p;
+
+ p.command = 0x4F;
+ p.num_data = 3;
+ p.s_buf = p.r_buf = p.data;
+ p.data[0] = 0;
+ p.data[1] = 0;
+ p.data[2] = level;
+ pmgrop();
+ return (0);
+}
+
Index: arch/macppc/dev/pm_direct.h
===
RCS file: /cvs/src/sys/arch/macppc/dev/pm_direct.h,v
retrieving revision 1.15
diff -u -p -r1.15 pm_direct.h
--- arch/macppc/dev/pm_direct.h 21 Oct 2022 22:42:36 - 1.15
+++ arch/macppc/dev/pm_direct.h 13 Jul 2023 21:17:24 -
@@ -67,6 +67,7 @@ struct pmu_battery_info
};
int pm_battery_info(int, struct pmu_battery_info *);
+int pmu_set_kbl(unsigned int);
void pm_eject_pcmcia(int);
void pmu_fileserver_mode(int);
Index: dev/hid/hidkbd.c
===
RCS file: /cvs/src/sys/dev/hid/hidkbd.c,v
retrieving revision 1.9
diff -u -p -r1.9 hidkbd.c
--- dev/hid/hidkbd.c9 Jul 2023 08:02:13 - 1.9
+++ dev/hid/hidkbd.c13 Jul 2023 21:17:42 -
@@ -143,6 +143,10 @@ static const struct hidkbd_translation a
{ 60, 127 },/* F3 -> audio mute */
{ 61, 129 },/* F4 -> audio lower */
{ 62, 128 },/* F5 -> audio raise */
+ { 63, 83 }, /* F6 -> num lock */
+ { 65, 234 },/* F8 -> backlight toggle*/
+ { 66, 236 },/* F9 -> backlight lower */
+ { 67, 235 },/* F10 -> backlight raise*/
#else
{ 63, 102 },/* F6 -> sleep */
{ 67, 127 },/* F10 -> audio mute */
@@ -569,6 +573,9 @@ hidkbd_decode(struct hidkbd *kbd, struct
case 129:
case 232:
case 233:
+ case 234:
+ case 235:
+ case 236:
wskbd_input(kbd->sc_wskbddev,
key & RELEASE ? WSCONS_EVENT_KEY_UP :
WSCONS_EVENT_KEY_DOWN, key & CODEMASK);
Index: dev/usb/makemap.awk
===
RCS file: /cvs/src/sys/dev/usb/makemap.awk,v
retrieving revision 1.16
diff -u -p -r1.16 makemap.awk
--- dev/usb/makemap.awk 9
Re: LibreSSL: Use of hardware enclaves to protect TLS keys
Thank you for sharing your suggestions and thoughts. I am working with Julius on a project and, after discussing it a bit, we really like the idea of making privilege separation for private keys in LibreSSL. First, it solves the problem when running on a non-virtualized OpenBSD. Second, it establishes a clear boundary for the use of private keys. It does seem like quite some work, but we will explore this direction further.
Re: bgpd: cleanup mrt.c
On Fri, Jul 14, 2023 at 11:43:38AM +0200, Claudio Jeker wrote:
> On Thu, Jul 13, 2023 at 11:36:22AM +0200, Theo Buehler wrote:
> > On Thu, Jul 13, 2023 at 10:04:33AM +0200, Claudio Jeker wrote:
> > > This is a follow-up to use more of the new ibuf API to write the mrt
> > > message.
> > >
> > > This removes all of the DUMP_XYZ macros and replaces them with
> > > ibuf_add_nX() calls. Also unify the error handling by using
> > > goto fail; in all cases and use a more generic log_warn() there once.
> >
> > The conversions all look correct, so that's ok.
> >
> > There are a few silent failures and a few double logs. The former should
> > be avoided and I think this should be done in this diff. I'm not sure
> > how much effort should be invested in fully avoiding the latter. It's a
> > bit messy:
> >
> > The only caller mrt_dump_entry_v2_rib() already logs an ibuf failure on
> > error, so there's no need to add a log to mrt_dump_entry_v2_rib()'s fail
> > label.
> >
> > In mrt_dump_hdr_se() there is no log after the fail: label. I think it
> > needs one, otherwise mrt_dump_{bgp_msg,state}() could fail silently.
> >
> > Most callers of mrt_dump_hdr_rde() will log an ibuf error on failure, so
> > you probably want to remove the log in the early return after ibuf_dynamic.
> >
> > Also, add a log (or goto fail) on mrt_dump_hdr_rde() failure in
> > mrt_dump_entry(). In particular, there is often a double log for the
> > 'unsupported type' case in mrt_dump_hdr_rde()...
>
> This is a cleaned up version following what you mentioned. I marked the
> internal functions with static and removed most logging from them and
> instead log only on the primary functions.
Yes, that's much cleaner now.
> I did not do this for those default cases in various switches. These
> errors are more like asserts and IIRC once were fatalx() calls but they
> got demoted to warnings to reduce the number of fatal errors in bgpd.
> Since these code paths are in most cases unreachable (unless a bug is
> introduced) I'm fine with the double logging.
Agreed. Totally makes sense.
ok tb
Re: bgpd: cleanup mrt.c
On Thu, Jul 13, 2023 at 11:36:22AM +0200, Theo Buehler wrote:
> On Thu, Jul 13, 2023 at 10:04:33AM +0200, Claudio Jeker wrote:
> > This is a follow-up to use more of the new ibuf API to write the mrt
> > message.
> >
> > This removes all of the DUMP_XYZ macros and replaces them with
> > ibuf_add_nX() calls. Also unify the error handling by using
> > goto fail; in all cases and use a more generic log_warn() there once.
>
> The conversions all look correct, so that's ok.
>
> There are a few silent failures and a few double logs. The former should
> be avoided and I think this should be done in this diff. I'm not sure
> how much effort should be invested in fully avoiding the latter. It's a
> bit messy:
>
> The only caller mrt_dump_entry_v2_rib() already logs an ibuf failure on
> error, so there's no need to add a log to mrt_dump_entry_v2_rib()'s fail
> label.
>
> In mrt_dump_hdr_se() there is no log after the fail: label. I think it
> needs one, otherwise mrt_dump_{bgp_msg,state}() could fail silently.
>
> Most callers of mrt_dump_hdr_rde() will log an ibuf error on failure, so
> you probably want to remove the log in the early return after ibuf_dynamic.
>
> Also, add a log (or goto fail) on mrt_dump_hdr_rde() failure in
> mrt_dump_entry(). In particular, there is often a double log for the
> 'unsupported type' case in mrt_dump_hdr_rde()...
This is a cleaned up version following what you mentioned. I marked the
internal functions with static and removed most logging from them and
instead log only on the primary functions.
I did not do this for those default cases in various switches. These
errors are more like asserts and IIRC once were fatalx() calls but they
got demoted to warnings to reduce the number of fatal errors in bgpd.
Since these code paths are in most cases unreachable (unless a bug is
introduced) I'm fine with the double logging.
--
:wq Claudio
Index: mrt.c
===
RCS file: /cvs/src/usr.sbin/bgpd/mrt.c,v
retrieving revision 1.115
diff -u -p -r1.115 mrt.c
--- mrt.c 12 Jul 2023 14:45:42 - 1.115
+++ mrt.c 14 Jul 2023 09:33:35 -
@@ -34,55 +34,19 @@
#include "mrt.h"
#include "log.h"
-int mrt_attr_dump(struct ibuf *, struct rde_aspath *, struct rde_community *,
-struct bgpd_addr *, int);
-int mrt_dump_entry_mp(struct mrt *, struct prefix *, uint16_t,
-struct rde_peer*);
-int mrt_dump_entry(struct mrt *, struct prefix *, uint16_t, struct rde_peer*);
-int mrt_dump_entry_v2(struct mrt *, struct rib_entry *, uint32_t);
-int mrt_dump_peer(struct ibuf *, struct rde_peer *);
-int mrt_dump_hdr_se(struct ibuf **, struct peer *, uint16_t, uint16_t,
-uint32_t, int);
-int mrt_dump_hdr_rde(struct ibuf **, uint16_t type, uint16_t, uint32_t);
-int mrt_open(struct mrt *, time_t);
-
-#define DUMP_BYTE(x, b)
\
- do {\
- u_char t = (b);\
- if (ibuf_add((x), , sizeof(t)) == -1) { \
- log_warn("mrt_dump1: ibuf_add error"); \
- goto fail; \
- } \
- } while (0)
-
-#define DUMP_SHORT(x, s) \
- do {\
- uint16_tt; \
- t = htons((s)); \
- if (ibuf_add((x), , sizeof(t)) == -1) { \
- log_warn("mrt_dump2: ibuf_add error"); \
- goto fail; \
- } \
- } while (0)
-
-#define DUMP_LONG(x, l)
\
- do {\
- uint32_tt; \
- t = htonl((l)); \
- if (ibuf_add((x), , sizeof(t)) == -1) { \
- log_warn("mrt_dump3: ibuf_add error"); \
- goto fail; \
- } \
- } while (0)
-
-#define DUMP_NLONG(x, l) \
- do {\
- uint32_tt = (l);\
- if (ibuf_add((x), , sizeof(t)) == -1) { \
- log_warn("mrt_dump4: ibuf_add error"); \
-
Re: rtwn: R92C_RXDW0_OWN -> R92C_TXDW0_OWN
On Fri, Jul 14, 2023 at 02:45:09PM +0800, Kevin Lo wrote:
> In rtwn_tx(), check if the OWN bit of Tx instead of Rx is set.
> Luckily, definitions of R92C_TXDW0_OWN and R92C_RXDW0_OWN are the same.
>
> ok?
ok stsp
> Index: sys/dev/pci/if_rtwn.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_rtwn.c,v
> retrieving revision 1.40
> diff -u -p -u -p -r1.40 if_rtwn.c
> --- sys/dev/pci/if_rtwn.c 21 Apr 2022 21:03:03 - 1.40
> +++ sys/dev/pci/if_rtwn.c 14 Jul 2023 06:43:06 -
> @@ -1022,7 +1022,7 @@ rtwn_tx(void *cookie, struct mbuf *m, st
>
> /* Fill Tx descriptor. */
> txd = _ring->desc[tx_ring->cur];
> - if (htole32(txd->txdw0) & R92C_RXDW0_OWN) {
> + if (htole32(txd->txdw0) & R92C_TXDW0_OWN) {
> m_freem(m);
> return (ENOBUFS);
> }
>
>
rtwn: R92C_RXDW0_OWN -> R92C_TXDW0_OWN
In rtwn_tx(), check if the OWN bit of Tx instead of Rx is set.
Luckily, definitions of R92C_TXDW0_OWN and R92C_RXDW0_OWN are the same.
ok?
Index: sys/dev/pci/if_rtwn.c
===
RCS file: /cvs/src/sys/dev/pci/if_rtwn.c,v
retrieving revision 1.40
diff -u -p -u -p -r1.40 if_rtwn.c
--- sys/dev/pci/if_rtwn.c 21 Apr 2022 21:03:03 - 1.40
+++ sys/dev/pci/if_rtwn.c 14 Jul 2023 06:43:06 -
@@ -1022,7 +1022,7 @@ rtwn_tx(void *cookie, struct mbuf *m, st
/* Fill Tx descriptor. */
txd = _ring->desc[tx_ring->cur];
- if (htole32(txd->txdw0) & R92C_RXDW0_OWN) {
+ if (htole32(txd->txdw0) & R92C_TXDW0_OWN) {
m_freem(m);
return (ENOBUFS);
}
