Re: ksh "clear-screen" for vi mode

2020-09-20 Thread Uwe Werler
On 20 Sep 06:14, Todd C. Miller wrote:
> On Sun, 20 Sep 2020 05:39:02 +0200, Theo Buehler wrote:
> 
> > This works and appears to match bash's behavior in that it only works
> > in normal mode. I would slightly prefer to also add the command to the
> > nonstandard vi commands in the switch around line 650 to have it
> > available from insert mode as well. This would match zsh's behavior.
> 
> Sure, I was comparing it to bash so didn't support insert mode.
> I agree that it's more useful to have it available there too.
> 
>  - todd
> 
> Index: bin/ksh/ksh.1
> ===
> RCS file: /cvs/src/bin/ksh/ksh.1,v
> retrieving revision 1.209
> diff -u -p -u -r1.209 ksh.1
> --- bin/ksh/ksh.1 7 Jul 2020 10:33:58 -   1.209
> +++ bin/ksh/ksh.1 20 Sep 2020 12:12:01 -
> @@ -5053,6 +5053,12 @@ Erases previous character.
>  .It ^J | ^M
>  End of line.
>  The current line is read, parsed, and executed by the shell.
> +.It ^L
> +Clear screen.
> +The screen is cleared if the
> +.Ev TERM
> +parameter is set and the terminal supports clearing the screen.
> +The prompt string and the current line are redrawn.
>  .It ^V
>  Literal next.
>  The next character typed is not treated specially (can be used
> Index: bin/ksh/vi.c
> ===
> RCS file: /cvs/src/bin/ksh/vi.c,v
> retrieving revision 1.56
> diff -u -p -u -r1.56 vi.c
> --- bin/ksh/vi.c  15 Mar 2018 16:51:29 -  1.56
> +++ bin/ksh/vi.c  20 Sep 2020 12:02:38 -
> @@ -14,12 +14,14 @@
>  #include 
>  #include 
>  #include 
> +#ifndef SMALL
> +# include 
> +# include 
> +#endif
>  
>  #include "sh.h"
>  #include "edit.h"
>  
> -#define CTRL(c)  (c & 0x1f)
> -
>  struct edstate {
>   char*cbuf;  /* main buffer to build the command line */
>   int cbufsize;   /* number of bytes allocated for cbuf */
> @@ -52,8 +54,9 @@ static int  Backword(int);
>  static int   Endword(int);
>  static int   grabhist(int, int);
>  static int   grabsearch(int, int, int, char *);
> +static void  do_clear_screen(void);
>  static void  redraw_line(int);
> -static void  refresh(int);
> +static void  refresh_line(int);
>  static int   outofwin(void);
>  static void  rewindow(void);
>  static int   newcol(int, int);
> @@ -271,9 +274,9 @@ vi_hook(int ch)
>   case 0:
>   if (state == VLIT) {
>   es->cursor--;
> - refresh(0);
> + refresh_line(0);
>   } else
> - refresh(insert != 0);
> + refresh_line(insert != 0);
>   break;
>   case 1:
>   return 1;
> @@ -298,7 +301,7 @@ vi_hook(int ch)
>   return -1;
>   } else if (putbuf("?", 1, 0) != 0)
>   return -1;
> - refresh(0);
> + refresh_line(0);
>   }
>   }
>   }
> @@ -310,7 +313,7 @@ vi_hook(int ch)
>   vi_error();
>   } else
>   es->cbuf[es->cursor++] = ch;
> - refresh(1);
> + refresh_line(1);
>   state = VNORMAL;
>   break;
>  
> @@ -375,7 +378,7 @@ vi_hook(int ch)
>   if (!srchpat[0]) {
>   vi_error();
>   state = VNORMAL;
> - refresh(0);
> + refresh_line(0);
>   return 0;
>   }
>   } else {
> @@ -392,17 +395,17 @@ vi_hook(int ch)
>   } while (srchlen > 0 &&
>   isu8cont(locpat[srchlen]));
>   es->cursor = es->linelen;
> - refresh(0);
> + refresh_line(0);
>   return 0;
>   }
>   restore_cbuf();
>   state = VNORMAL;
> - refresh(0);
> + refresh_line(0);
>   } else if (ch == edchars.kill) {
>   srchlen = 0;
>   es->linelen = 1;
>   es->cursor = 1;
> - refresh(0);
> + refresh_line(0);
>   return 0;
>   } else if (ch == edchars.werase) {
>   struct edstate new_es, *save_es;
> @@ -421,7 +424,7 @@ vi_hook(int ch)

Re: ksh "clear-screen" for vi mode

2020-09-20 Thread Uwe Werler
On 20 Sep 05:39, Theo Buehler wrote:
> On Sat, Sep 19, 2020 at 03:50:52PM -0600, Todd C. Miller wrote:
> > The vi and emacs edit code are completely separate.  Try the following
> > diff.  I had to rename a few things to avoid clashing with ncurses.h.
> 
> This works and appears to match bash's behavior in that it only works
> in normal mode. I would slightly prefer to also add the command to the
> nonstandard vi commands in the switch around line 650 to have it
> available from insert mode as well. This would match zsh's behavior.

That would be really great.

> 
> Either way, ok tb
> 



Re: net80211: skip input block ack window gaps faster

2020-07-17 Thread Uwe Werler
pci0 dev 21 function 2 not configured
"Intel 100 Series MEI" rev 0x21 at pci0 dev 22 function 0 not configured
ahci0 at pci0 dev 23 function 0 "Intel 100 Series AHCI" rev 0x21: msi, AHCI 
1.3.1
ahci0: port 2: 6.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 2 lun 0:  naa.500a075119d7587b
sd0: 244198MB, 512 bytes/sector, 500118192 sectors, thin
ppb0 at pci0 dev 28 function 0 "Intel 100 Series PCIE" rev 0xf1: msi
pci1 at ppb0 bus 1
rtsx0 at pci1 dev 0 function 0 "Realtek RTS525A Card Reader" rev 0x01: msi
sdmmc0 at rtsx0: 4-bit, dma
ppb1 at pci0 dev 28 function 2 "Intel 100 Series PCIE" rev 0xf1: msi
pci2 at ppb1 bus 2
iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, msi
ppb2 at pci0 dev 28 function 4 "Intel 100 Series PCIE" rev 0xf1: msi
pci3 at ppb2 bus 3
pcib0 at pci0 dev 31 function 0 "Intel 200 Series LPC" rev 0x21
"Intel 100 Series PMC" rev 0x21 at pci0 dev 31 function 2 not configured
azalia0 at pci0 dev 31 function 3 "Intel 200 Series HD Audio" rev 0x21: msi
azalia0: codecs: Realtek/0x0256, Intel/0x280b, using Realtek/0x0256
audio0 at azalia0
ichiic0 at pci0 dev 31 function 4 "Intel 100 Series SMBus" rev 0x21: apic 2 int 
16
iic2 at ichiic0
spdmem0 at iic2 addr 0x50: 8GB DDR4 SDRAM PC4-19200 SO-DIMM
spdmem1 at iic2 addr 0x52: 8GB DDR4 SDRAM PC4-19200 SO-DIMM
em0 at pci0 dev 31 function 6 "Intel I219-LM" rev 0x21: msi, address 
a4:4c:c8:7e:52:d3
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd1 at pckbd0: console keyboard
pms0 at pckbc0 (aux slot)
wsmouse1 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
vmm0 at mainbus0: VMX/EPT
efifb at mainbus0 not configured
uhidev0 at uhub0 port 2 configuration 1 interface 0 "Logitech USB-PS/2 Optical 
Mouse" rev 2.00/20.00 addr 2
uhidev0: iclass 3/1
ums0 at uhidev0: 3 buttons, Z dir
wsmouse2 at ums0 mux 0
uvideo0 at uhub0 port 5 configuration 1 interface 0 "CN0K49W1LOG007B8BMGNA01 
Integrated_Webcam_HD" rev 2.00/75.24 addr 3
video0 at uvideo0
ugen0 at uhub0 port 7 "Intel Bluetooth" rev 2.00/0.10 addr 4
ugen1 at uhub0 port 10 "Broadcom Corp 5880" rev 1.10/1.01 addr 5
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
sd1 at scsibus3 targ 1 lun 0: 
sd1: 244190MB, 512 bytes/sector, 500101898 sectors
root on sd1a (42a289e5051cfa2f.a) swap on sd1b dump on sd1b
inteldrm0: 1920x1080, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd1
wskbd0: connecting to wsdisplay0
wsdisplay0: screen 1-5 added (std, vt100 emulation)
iwm0: hw rev 0x230, fw ver 34.0.1, address 60:f6:77:bc:3a:04

Please tell me what else I can test.

-- 

With kind regards / Með bestu kveðju / Mit freundlichen Grüßen

Uwe Werler



Re: 11n Tx aggregation for iwm(4)

2020-06-29 Thread Uwe Werler
Woahhh,

was also trying 5GHz (and tcpbench against one of our bsd servers in DMZ):

469651560 bytes sent over 85.291 seconds
bandwidth min/avg/max/std-dev = 3.475/43.927/87.071/29.809 Mbps


6 new output block ack agreements
0 output block ack agreements timed out

(Tomorrow @work I will test against our new APs. My AP @home is a Technicolor 
MediaAccess TG789vac).

mbk Uwe

On 29 Jun 09:48, Uwe Werler wrote:
> Hi Stefan,
> 
> for me the patch works in mode 11n:
> 
> before (OpenBSD 6.7-current (GENERIC.MP) #304: Fri Jun 26 02:08:50 MDT 2020)
> bandwidth min/avg/max/std-dev = 2.354/12.319/15.391/3.850 Mbps
> 
> with patch (OpenBSD 6.7-current (GENERIC.MP) #0: Mon Jun 29 09:35:24 GMT 2020)
> bandwidth min/avg/max/std-dev = 12.174/31.411/57.746/15.154 Mbps
> 
> iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, msi
> iwm0: hw rev 0x230, fw ver 34.0.1, address 60:f6:77:bc:3a:04
> 
> (mode 11g: bandwidth min/avg/max/std-dev = 0.620/0.844/1.101/0.153 Mbps)
> 
> mbk Uwe
> 
> 
> On 26 Jun 14:45, Stefan Sperling wrote:
> > This patch adds support for 11n Tx aggregation to iwm(4).
> > 
> > Please help with testing if you can by running the patch and using wifi
> > as usual. Nothing should change, except that Tx speed may potentially
> > improve. If you have time to run before/after performance measurements with
> > tcpbench or such, that would be nice. But it's not required for testing.
> > 
> > If Tx aggregation is active then netstat will show a non-zero output block 
> > ack
> > agreement counter:
> > 
> > $ netstat -W iwm0 | grep 'output block'
> > 3 new output block ack agreements
> > 0 output block ack agreements timed out
> > 
> > It would be great to get at least one test for all the chipsets the driver
> > supports: 7260, 7265, 3160, 3165, 3168, 8260, 8265, 9260, 9560
> > The behaviour of the access point also matters a great deal. It won't
> > hurt to test the same chipset against several different access points.
> > 
> > I have tested this version on 8265 only so far. I've run older revisions
> > of this patch on 7265 so I'm confident that this chip will work, too.
> > So far, the APs I have tested against are athn(4) in 11a mode and in 11n
> > mode with the 'nomimo' nwflag, and a Sagemcom 11ac AP. All on 5Ghz channels.
> > 
> > diff refs/heads/master refs/heads/txagg
> > blob - 3a75d07a60a7eb4c66540474e47aeffd7a85250a
> > blob + 853bdd1290ad509f5fce7b5bf20550f458a2b460
> > --- sys/dev/pci/if_iwm.c
> > +++ sys/dev/pci/if_iwm.c
> > @@ -144,6 +144,8 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include  /* for SEQ_LT */
> > +#undef DPRINTF /* defined in ieee80211_priv.h */
> >  
> >  #define DEVNAME(_s)((_s)->sc_dev.dv_xname)
> >  
> > @@ -299,7 +301,8 @@ int iwm_nic_rx_mq_init(struct iwm_softc *);
> >  intiwm_nic_tx_init(struct iwm_softc *);
> >  intiwm_nic_init(struct iwm_softc *);
> >  intiwm_enable_ac_txq(struct iwm_softc *, int, int);
> > -intiwm_enable_txq(struct iwm_softc *, int, int, int);
> > +intiwm_enable_txq(struct iwm_softc *, int, int, int, int, uint8_t,
> > +   uint16_t);
> >  intiwm_post_alive(struct iwm_softc *);
> >  struct iwm_phy_db_entry *iwm_phy_db_get_section(struct iwm_softc *, 
> > uint16_t,
> > uint16_t);
> > @@ -334,12 +337,12 @@ void  iwm_ampdu_rx_stop(struct ieee80211com *, struct 
> > i
> > uint8_t);
> >  void   iwm_sta_rx_agg(struct iwm_softc *, struct ieee80211_node *, 
> > uint8_t,
> > uint16_t, uint16_t, int);
> > -#ifdef notyet
> > +void   iwm_sta_tx_agg(struct iwm_softc *, struct ieee80211_node *, 
> > uint8_t,
> > +   uint16_t, uint16_t, int);
> >  intiwm_ampdu_tx_start(struct ieee80211com *, struct ieee80211_node 
> > *,
> > uint8_t);
> >  void   iwm_ampdu_tx_stop(struct ieee80211com *, struct ieee80211_node 
> > *,
> > uint8_t);
> > -#endif
> >  void   iwm_ba_task(void *);
> >  
> >  intiwm_parse_nvm_data(struct iwm_softc *, const uint16_t *,
> > @@ -372,14 +375,25 @@ int   iwm_rxmq_get_signal_strength(struct iwm_softc 
> > *, s
> >  void   iwm_rx_rx_phy_cmd(struct iwm_softc *, struct iwm_rx_packet *,
> > struct iwm_rx_data *);
> >  intiwm_get_noise(const struct iwm_statistics_rx_non_phy *);
> > +void   iwm_txq_advance(struct iwm_softc *, struct iwm_tx_ring *, int);
> > +void   iwm_ampdu_tx_done(struct iwm_softc 

Re: 11n Tx aggregation for iwm(4)

2020-06-29 Thread Uwe Werler
Hi Stefan,

for me the patch works in mode 11n:

before (OpenBSD 6.7-current (GENERIC.MP) #304: Fri Jun 26 02:08:50 MDT 2020)
bandwidth min/avg/max/std-dev = 2.354/12.319/15.391/3.850 Mbps

with patch (OpenBSD 6.7-current (GENERIC.MP) #0: Mon Jun 29 09:35:24 GMT 2020)
bandwidth min/avg/max/std-dev = 12.174/31.411/57.746/15.154 Mbps

iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, msi
iwm0: hw rev 0x230, fw ver 34.0.1, address 60:f6:77:bc:3a:04

(mode 11g: bandwidth min/avg/max/std-dev = 0.620/0.844/1.101/0.153 Mbps)

mbk Uwe


On 26 Jun 14:45, Stefan Sperling wrote:
> This patch adds support for 11n Tx aggregation to iwm(4).
> 
> Please help with testing if you can by running the patch and using wifi
> as usual. Nothing should change, except that Tx speed may potentially
> improve. If you have time to run before/after performance measurements with
> tcpbench or such, that would be nice. But it's not required for testing.
> 
> If Tx aggregation is active then netstat will show a non-zero output block ack
> agreement counter:
> 
> $ netstat -W iwm0 | grep 'output block'
> 3 new output block ack agreements
>   0 output block ack agreements timed out
> 
> It would be great to get at least one test for all the chipsets the driver
> supports: 7260, 7265, 3160, 3165, 3168, 8260, 8265, 9260, 9560
> The behaviour of the access point also matters a great deal. It won't
> hurt to test the same chipset against several different access points.
> 
> I have tested this version on 8265 only so far. I've run older revisions
> of this patch on 7265 so I'm confident that this chip will work, too.
> So far, the APs I have tested against are athn(4) in 11a mode and in 11n
> mode with the 'nomimo' nwflag, and a Sagemcom 11ac AP. All on 5Ghz channels.
> 
> diff refs/heads/master refs/heads/txagg
> blob - 3a75d07a60a7eb4c66540474e47aeffd7a85250a
> blob + 853bdd1290ad509f5fce7b5bf20550f458a2b460
> --- sys/dev/pci/if_iwm.c
> +++ sys/dev/pci/if_iwm.c
> @@ -144,6 +144,8 @@
>  #include 
>  #include 
>  #include 
> +#include  /* for SEQ_LT */
> +#undef DPRINTF /* defined in ieee80211_priv.h */
>  
>  #define DEVNAME(_s)  ((_s)->sc_dev.dv_xname)
>  
> @@ -299,7 +301,8 @@ int   iwm_nic_rx_mq_init(struct iwm_softc *);
>  int  iwm_nic_tx_init(struct iwm_softc *);
>  int  iwm_nic_init(struct iwm_softc *);
>  int  iwm_enable_ac_txq(struct iwm_softc *, int, int);
> -int  iwm_enable_txq(struct iwm_softc *, int, int, int);
> +int  iwm_enable_txq(struct iwm_softc *, int, int, int, int, uint8_t,
> + uint16_t);
>  int  iwm_post_alive(struct iwm_softc *);
>  struct iwm_phy_db_entry *iwm_phy_db_get_section(struct iwm_softc *, uint16_t,
>   uint16_t);
> @@ -334,12 +337,12 @@ voidiwm_ampdu_rx_stop(struct ieee80211com *, struct 
> i
>   uint8_t);
>  void iwm_sta_rx_agg(struct iwm_softc *, struct ieee80211_node *, uint8_t,
>   uint16_t, uint16_t, int);
> -#ifdef notyet
> +void iwm_sta_tx_agg(struct iwm_softc *, struct ieee80211_node *, uint8_t,
> + uint16_t, uint16_t, int);
>  int  iwm_ampdu_tx_start(struct ieee80211com *, struct ieee80211_node *,
>   uint8_t);
>  void iwm_ampdu_tx_stop(struct ieee80211com *, struct ieee80211_node *,
>   uint8_t);
> -#endif
>  void iwm_ba_task(void *);
>  
>  int  iwm_parse_nvm_data(struct iwm_softc *, const uint16_t *,
> @@ -372,14 +375,25 @@ int iwm_rxmq_get_signal_strength(struct iwm_softc 
> *, s
>  void iwm_rx_rx_phy_cmd(struct iwm_softc *, struct iwm_rx_packet *,
>   struct iwm_rx_data *);
>  int  iwm_get_noise(const struct iwm_statistics_rx_non_phy *);
> +void iwm_txq_advance(struct iwm_softc *, struct iwm_tx_ring *, int);
> +void iwm_ampdu_tx_done(struct iwm_softc *, struct iwm_cmd_header *,
> + struct iwm_node *, struct iwm_tx_ring *, uint32_t, uint8_t,
> + uint8_t, uint16_t, int, struct iwm_agg_tx_status *);
>  int  iwm_ccmp_decap(struct iwm_softc *, struct mbuf *,
>   struct ieee80211_node *);
>  void iwm_rx_frame(struct iwm_softc *, struct mbuf *, int, uint32_t, int, int,
>   uint32_t, struct ieee80211_rxinfo *, struct mbuf_list *);
> -void iwm_rx_tx_cmd_single(struct iwm_softc *, struct iwm_rx_packet *,
> - struct iwm_node *, int, int);
> +void iwm_rx_tx_cmd_single(struct iwm_softc *, struct iwm_tx_resp *,
> + struct iwm_node *, int, int, int);
> +void iwm_txd_done(struct iwm_softc *, struct iwm_tx_data *);
>  void iwm_rx_tx_cmd(struct iwm_softc *, struct iwm_rx_packet *,
>   struct iwm_rx_data *);
> +void iwm_clear_oactive(struct iwm_softc *, struct iwm_tx_ring *);
> +void iwm_mira_choose(struct iwm_softc *, struct ieee80211_node *);
> +void iwm_ampdu_rate_control(struct iwm_softc *, struct ieee80211_node *,
> + struct iwm_tx_ring *, int, uint16_t, uint16_t);
> +void iwm_rx_ba(struct iwm_softc *, struct iwm_rx_packet *,
> + struct iwm_rx_data *);
>  void iwm_rx_bmiss(struct iwm_softc *, struct iwm_rx_packet *,
>   

PATCH: configurable tiling in cwm(1)

2020-03-26 Thread Uwe Werler
Hello @tech,

with this diff https://marc.info/?l=openbsd-tech=149192690925713=2 the
behaviour of cwm changed so vtile and htile always use 50% of the screen.

This is a reasonable default but sometimes I want to have the master windows
be bigger.

Inspired by this patch https://marc.info/?l=openbsd-tech=154887686615696=2
I suggest the following diff.

This adds two new config options "htile percent" and "vtile percent" which
define how much of the screen the current windows should occupy as the master
window. If set to "0" then the old behaviour is restored where the current
vertical or horizontal size of the window defines the size of the master
window. If unset the current behaviour is unchaged that means the master
windows uses half of the screen size.

For example in .cwmrc:

htile 66
vtile 0

For window-htile the master window will occupy 66% of the screen high or for
window-vtile the current window width defines the screen width of the master
window.

Any thoughts?

Regards Uwe


Index: calmwm.h
===
RCS file: /cvs/xenocara/app/cwm/calmwm.h,v
retrieving revision 1.374
diff -u -p -r1.374 calmwm.h
--- calmwm.h24 Mar 2020 14:47:29 -  1.374
+++ calmwm.h27 Mar 2020 00:09:43 -
@@ -291,6 +291,8 @@ struct conf {
int  bwidth;
int  mamount;
int  snapdist;
+   int  htile;
+   int  vtile;
struct gap   gap;
char*color[CWM_COLOR_NITEMS];
char*font;
Index: client.c
===
RCS file: /cvs/xenocara/app/cwm/client.c,v
retrieving revision 1.262
diff -u -p -r1.262 client.c
--- client.c24 Mar 2020 14:47:29 -  1.262
+++ client.c27 Mar 2020 00:09:43 -
@@ -940,7 +940,8 @@ client_htile(struct client_ctx *cc)
cc->geom.x = area.x;
cc->geom.y = area.y;
cc->geom.w = area.w - (cc->bwidth * 2);
-   cc->geom.h = (area.h - (cc->bwidth * 2)) / 2;
+  if (Conf.htile > 0)
+   cc->geom.h = ((area.h - (cc->bwidth * 2)) * Conf.htile) / 100;
client_resize(cc, 1);
client_ptr_warp(cc);
 
@@ -1007,7 +1008,8 @@ client_vtile(struct client_ctx *cc)
cc->flags &= ~CLIENT_VMAXIMIZED;
cc->geom.x = area.x;
cc->geom.y = area.y;
-   cc->geom.w = (area.w - (cc->bwidth * 2)) / 2;
+  if (Conf.vtile > 0)
+   cc->geom.w = ((area.w - (cc->bwidth * 2)) * Conf.vtile) / 100;
cc->geom.h = area.h - (cc->bwidth * 2);
client_resize(cc, 1);
client_ptr_warp(cc);
Index: conf.c
===
RCS file: /cvs/xenocara/app/cwm/conf.c,v
retrieving revision 1.251
diff -u -p -r1.251 conf.c
--- conf.c  27 Feb 2020 14:56:39 -  1.251
+++ conf.c  27 Mar 2020 00:09:43 -
@@ -281,6 +281,8 @@ conf_init(struct conf *c)
c->stickygroups = 0;
c->bwidth = 1;
c->mamount = 1;
+   c->htile = 50;
+   c->vtile = 50;
c->snapdist = 0;
c->ngroups = 0;
c->nameqlen = 5;
Index: cwmrc.5
===
RCS file: /cvs/xenocara/app/cwm/cwmrc.5,v
retrieving revision 1.75
diff -u -p -r1.75 cwmrc.5
--- cwmrc.5 13 Mar 2020 20:50:07 -  1.75
+++ cwmrc.5 27 Mar 2020 00:09:43 -
@@ -183,6 +183,11 @@ This
 can be used for applications such as
 .Xr xclock 1 ,
 where the user may wish to remain visible.
+.It Ic htile Ar percent
+The amount of the screen the master window should be resized to when
+.Ic window-htile
+is called. If set to 0 then the size is the vertical size of current current
+window.
 .It Ic ignore Ar windowname
 Ignore, and do not warp to, windows with the name
 .Ar windowname
@@ -216,6 +221,11 @@ A special
 keyword
 .Dq all
 can be used to unbind all buttons.
+.It Ic vtile Ar percent
+The amount of the screen the master window should be resized to when
+.Ic window-vtile
+is called. If set to 0 then the size is the horizontal size of the current
+window.
 .It Ic wm Ar name path
 Every
 .Ar name
@@ -303,11 +313,15 @@ Vertically maximize current window (gap 
 Horizontally maximize current window (gap + border honored).
 .It window-htile
 Current window is placed at the top of the screen, maximized
-horizontally and resized to half of the vertical screen space.
+horizontally and resized to
+.Ar htile
+(default half) of the vertical screen space.
 Other windows in its group share remaining screen space.
 .It window-vtile
 Current window is placed on the left of the screen, maximized vertically
-and resized to half of the horizontal screen space.
+and resized to
+.Ar vtile
+(default half) of the horizontal screen space.
 Other windows in its group share remaining screen space.
 .It window-move
 Move current window.
Index: parse.y

Re: cwm: remove menu-ssh

2020-01-23 Thread Uwe Werler
rofi. It's in the ports.

Am 23. Januar 2020 15:01:54 GMT+00:00 schrieb Mikhail :
>Can you elaborate on tools for menu-ssh replacement?
>
>On Wed, Jan 22, 2020 at 11:16 PM Okan Demirmen 
>wrote:
>>
>> Hi,
>>
>> I think we've (or at least I have) mused about this for a while; a
>> recent mail reminded me that this feature should go - a window
>manager
>> doesn't need to parse the ssh known_hosts file for a menu; there are
>> better tools for this.
>>
>> Remove menu-ssh.
>>
>> okay?
>>
>> Index: calmwm.h
>> ===
>> RCS file: /home/open/cvs/xenocara/app/cwm/calmwm.h,v
>> retrieving revision 1.372
>> diff -u -p -r1.372 calmwm.h
>> --- calmwm.h22 Jan 2020 19:58:35 -  1.372
>> +++ calmwm.h22 Jan 2020 20:09:13 -
>> @@ -304,7 +304,6 @@ struct conf {
>> int  xrandr;
>> int  xrandr_event_base;
>> char*conf_file;
>> -   char*known_hosts;
>> char*wm_argv;
>> int  debug;
>>  };
>> @@ -517,7 +516,6 @@ void kbfunc_menu_cmd(void
>*, struct c
>>  voidkbfunc_menu_group(void *, struct cargs *);
>>  voidkbfunc_menu_wm(void *, struct cargs *);
>>  voidkbfunc_menu_exec(void *, struct cargs *);
>> -voidkbfunc_menu_ssh(void *, struct cargs *);
>>  voidkbfunc_client_menu_label(void *, struct
>cargs *);
>>  voidkbfunc_exec_cmd(void *, struct cargs *);
>>  voidkbfunc_exec_lock(void *, struct cargs *);
>> Index: conf.c
>> ===
>> RCS file: /home/open/cvs/xenocara/app/cwm/conf.c,v
>> retrieving revision 1.249
>> diff -u -p -r1.249 conf.c
>> --- conf.c  7 Mar 2019 12:54:21 -   1.249
>> +++ conf.c  22 Jan 2020 20:09:24 -
>> @@ -179,7 +179,6 @@ static const struct {
>>
>> { FUNC_SC(menu-cmd, menu_cmd, 0) },
>> { FUNC_SC(menu-group, menu_group, 0) },
>> -   { FUNC_SC(menu-ssh, menu_ssh, 0) },
>> { FUNC_SC(menu-window, menu_client, CWM_MENU_WINDOW_ALL) },
>> { FUNC_SC(menu-window-hidden, menu_client,
>CWM_MENU_WINDOW_HIDDEN) },
>> { FUNC_SC(menu-exec, menu_exec, 0) },
>> @@ -210,7 +209,6 @@ static const struct {
>> { "CM-Delete",  "lock" },
>> { "M-question", "menu-exec" },
>> { "CM-w",   "menu-exec-wm" },
>> -   { "M-period",   "menu-ssh" },
>> { "M-Return",   "window-hide" },
>> { "M-Down", "window-lower" },
>> { "M-Up",   "window-raise" },
>> @@ -316,7 +314,6 @@ conf_init(struct conf *c)
>> home = "/";
>> }
>> xasprintf(>conf_file, "%s/%s", home, ".cwmrc");
>> -   xasprintf(>known_hosts, "%s/%s", home,
>".ssh/known_hosts");
>>  }
>>
>>  void
>> @@ -363,7 +360,6 @@ conf_clear(struct conf *c)
>> free(c->color[i]);
>>
>> free(c->conf_file);
>> -   free(c->known_hosts);
>> free(c->font);
>> free(c->wmname);
>>  }
>> Index: cwm.1
>> ===
>> RCS file: /home/open/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   22 Jan 2020 20:08:19 -
>> @@ -140,15 +140,6 @@ Resize window by a large amount; see
>>  Spawn
>>  .Dq exec program
>>  dialog.
>> -.It Ic M-period
>> -Spawn
>> -.Dq ssh to
>> -dialog.
>> -This parses
>> -.Pa $HOME/.ssh/known_hosts
>> -to provide host auto-completion.
>> -.Xr ssh 1
>> -will be executed via the configured terminal emulator.
>>  .It Ic CM-w
>>  Spawn
>>  .Dq exec WindowManager
>> Index: cwmrc.5
>> ===
>> RCS file: /home/open/cvs/xenocara/app/cwm/cwmrc.5,v
>> retrieving revision 1.73
>> diff -u -p -r1.73 cwmrc.5
>> --- cwmrc.5 2 Jul 2019 23:37:47 -   1.73
>> +++ cwmrc.5 22 Jan 2020 20:07:57 -
>> @@ -280,10 +280,6 @@ menu.
>>  Launch
>>  .Dq exec WindowManager
>>  menu.
>> -.It menu-ssh
>> -Launch
>> -.Dq ssh
>> -menu.
>>  .It group-toggle-[n]
>>  Toggle visibility of group n, where n is 1-9.
>>  .It group-only-[n]
>> Index: kbfunc.c
>> ===
>> RCS file: /home/open/cvs/xenocara/app/cwm/kbfunc.c,v
>> retrieving revision 1.167
>> diff -u -p -r1.167 kbfunc.c
>> --- kbfunc.c21 Jan 2020 15:50:03 -  1.167
>> +++ kbfunc.c22 Jan 2020 20:09:03 -
>> @@ -647,72 +647,6 @@ out:
>>  }
>>
>>  void
>> -kbfunc_menu_ssh(void *ctx, struct cargs *cargs)
>> -{
>> -   struct screen_ctx   *sc = ctx;
>> -   struct cmd_ctx  *cmd;
>> -   struct menu *mi;
>> -   struct menu_qmenuq;
>> 

Re: vmd: VMs with auto-configured L3 interfaces (call for testing)

2017-04-12 Thread Uwe Werler
Thanks Reyk for Your great work!

Tested and works like a charm. Made some tcpbench tests too and got ~180 MBit
between host and vm.

Regards Uwe


On 12 Apr 13:44, Reyk Floeter wrote:
> Hi,
> 
> we want to make it easier to run NAT'ed and auto-configured VMs that
> don't need switches, L2, manual scripts, or any additional servers on
> the host.  I wrote a new mode that just needs vmd, pf, and forwarding.
> 
> I'm looking for feedback, testing, and responses on this list.
> 
> vmd currently supports two modes to configure network interfaces:
> -i/interface: unconfigured tap(4) interfaces for static configuration.
> -n/switch: automatically adds tap(4) interfaces to bridge/switch interfaces.
> 
> The attached diff adds a new mode for dynamic "NAT" interfaces:
> -L/local interface: auto-configure an L3 interface and run built-in DHCP.
> 
> Setting it up is easy:
> 
> 1. Enable forwarding:
> 
> # sysctl net.inet.ip.forwarding=1
> 
> 2. Add a NAT rule to pf.conf(5) and a redirection for DNS (or run unbound):
> 
> pass out on egress received-on tap nat-to (egress:0)
> pass in on tap proto { tcp udp } to 100.64.0.0/10 port domain rdr-to 
> 8.8.8.8
> 
> 3. Now start a new VM with the -L option to add a "local" interface:
> 
> # vmctl start foo -d foo.img -L -c
> 
> vmd configures a /31 address on the tap(4) interface of the host and
> provides another IP in the same subnet via DHCP (BOOTP) to the VM.
> vmd runs an internal DHCP server that replies with IP, gateway, and
> DNS addresses to the VM - there is no need to run dhcpd!  The built-in
> server only ever responds to the VM on the inside and cannot leak its
> DHCP responses to the outside.
> 
> DHCPDISCOVER on vio0 - interval 1
> BOOTREPLY from 100.64.3.2 (fe:e1:bb:d1:b7:5e)
> bound to 100.64.3.3 -- renewal in 8000 seconds.
> 
> Done.
> 
> This also replaces the "dhcpd on vether0 on switch" approach for
> NAT'ed VMs on laptops that I recommended before.  The switch concept
> itself will still be provided and improved for other use cases.
> 
> The addresses are currently allocated from the RFC6598 100.64.0.0/10
> "IPv4 Prefix for Shared Address Space" to avoid collisions with
> RFC1918 addresses on the host.  I will add a configuration option to
> change the default prefix later.
> 
> The current algorithm to generate the IPs and /31 subnets from the
> prefix can be found in the vm_priv_addr() function below.  The
> packet.c and dhcp.h code is copied from dhcrelay which got improved
> recently.
> 
> Thoughts? OKs?
> 
> Reyk
> 
> Index: usr.sbin/vmd/Makefile
> ===
> RCS file: /cvs/src/usr.sbin/vmd/Makefile,v
> retrieving revision 1.13
> diff -u -p -u -p -r1.13 Makefile
> --- usr.sbin/vmd/Makefile 1 Mar 2017 18:00:50 -   1.13
> +++ usr.sbin/vmd/Makefile 12 Apr 2017 11:16:50 -
> @@ -5,7 +5,7 @@
>  PROG=vmd
>  SRCS=vmd.c control.c log.c priv.c proc.c config.c vmm.c
>  SRCS+=   vm.c loadfile_elf.c pci.c virtio.c i8259.c mc146818.c
> -SRCS+=   ns8250.c i8253.c vmboot.c ufs.c disklabel.c
> +SRCS+=   ns8250.c i8253.c vmboot.c ufs.c disklabel.c dhcp.c 
> packet.c
>  SRCS+=   parse.y
>  
>  CFLAGS+= -Wall -I${.CURDIR}
> Index: usr.sbin/vmd/dhcp.c
> ===
> RCS file: usr.sbin/vmd/dhcp.c
> diff -N usr.sbin/vmd/dhcp.c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ usr.sbin/vmd/dhcp.c   12 Apr 2017 11:16:50 -
> @@ -0,0 +1,163 @@
> +/*   $OpenBSD$   */
> +
> +/*
> + * Copyright (c) 2017 Reyk Floeter 
> + *
> + * Permission to use, copy, modify, and distribute this software for any
> + * purpose with or without fee is hereby granted, provided that the above
> + * copyright notice and this permission notice appear in all copies.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> + */
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "proc.h"
> +#include "vmd.h"
> +#include "dhcp.h"
> +#include "virtio.h"
> +
> +static const uint8_t broadcast[6] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff };
> +
> +ssize_t
> +dhcp_request(struct vionet_dev *dev, char *buf, size_t buflen, char **obuf)
> +{
> + unsigned char   *respbuf = NULL;
> + ssize_t  offset, respbuflen = 0;
> + struct packet_ctxpc;
> + struct 

Re: 11n support for athn(4)

2017-01-18 Thread Uwe Werler
On 16. Jan 17:46:48, Uwe Werler wrote:
> 
> Unfortunately the throughput is very low, only ~7 MBit. With mode 11g I get 
> ~16 MBit.
> 
> 
> zarathustra:~# tcpbench apu01
>   elapsed_ms  bytes mbps   bwidth
> 1004 7482725.962  100.00%
> Conn:   1 Mbps:5.962 Peak Mbps:5.962 Avg Mbps:5.962
> 2007 8396646.697  100.00%
> Conn:   1 Mbps:6.697 Peak Mbps:6.697 Avg Mbps:6.697
> 3010 8182446.533  100.00%
> Conn:   1 Mbps:6.533 Peak Mbps:6.697 Avg Mbps:6.533
> 4013 9096367.255  100.00%
> Conn:   1 Mbps:7.255 Peak Mbps:7.255 Avg Mbps:7.255
> 5014 8568006.848  100.00%
> Conn:   1 Mbps:6.848 Peak Mbps:7.255 Avg Mbps:6.848
> 6015 8682246.946  100.00%
> Conn:   1 Mbps:6.946 Peak Mbps:7.255 Avg Mbps:6.946
> 7021 8725086.945  100.00%
> Conn:   1 Mbps:6.945 Peak Mbps:7.255 Avg Mbps:6.945
> 8023 8353806.670  100.00%
> Conn:   1 Mbps:6.670 Peak Mbps:7.255 Avg Mbps:6.670
> 9025 8482326.779  100.00%
> Conn:   1 Mbps:6.779 Peak Mbps:7.255 Avg Mbps:6.779
>10028 8439486.731  100.00%
> Conn:   1 Mbps:6.731 Peak Mbps:7.255 Avg Mbps:6.731
>11036 8310966.596  100.00%
> Conn:   1 Mbps:6.596 Peak Mbps:7.255 Avg Mbps:6.596
> 
> I'm now ready to test furhter.
> 

I tested yesterday with my Android phone (Galaxy S7) and got only ~4 MBit.



Re: 11n support for athn(4)

2017-01-16 Thread Uwe Werler
Hello Stefan,

many many thanks for this work!

I tested today with the latest snapshot from yesterday and a custom compiled 
kernel
from today's sources. AP is my APU1D4 and Client is my ThinkPad T530 with iwn:

AP:

athn0 at pci4 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 19
athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:17:40:ba

athn0: flags=8947 mtu 1500
lladdr 04:f0:21:17:40:ba
index 4 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect (autoselect hostap)
status: active
ieee80211: nwid TEST chan 1 bssid 04:f0:21:17:40:ba wpakey XXX 
wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp

athn0: sending auth to 6c:88:14:36:27:b0 on channel 1 mode auto
athn0: station 6c:88:14:36:27:b0 newly authenticated (open)
athn0: sending assoc_resp to 6c:88:14:36:27:b0 on channel 1 mode auto
athn0: sending msg 1/4 of the 4-way handshake to 6c:88:14:36:27:b0
athn0: received auth from 6c:88:14:36:27:b0 rssi 34 mode auto
athn0: received assoc_req from 6c:88:14:36:27:b0 rssi 33 mode auto
athn0: sending msg 1/4 of the 4-way handshake to 6c:88:14:36:27:b0
athn0: received msg 2/4 of the 4-way handshake from 6c:88:14:36:27:b0
athn0: sending msg 3/4 of the 4-way handshake to 6c:88:14:36:27:b0
athn0: received msg 4/4 of the 4-way handshake from 6c:88:14:36:27:b0

Client:

iwn0 at pci2 dev 0 function 0 "Intel Centrino Advanced-N 6205" rev 0x34: msi, 
MIMO 2T2R, MoW, address 6c:88:14:36:27:b0

iwn0: end active scan
iwn0: sending auth to 04:f0:21:17:40:ba on channel 1 mode 11g
iwn0: sending assoc_req to 04:f0:21:17:40:ba on channel 1 mode 11g
iwn0: received auth from 04:f0:21:17:40:ba rssi -20 mode 11g
iwn0: associated with 04:f0:21:17:40:ba ssid "TEST" channel 1 start MCS 0 short 
preamble long slot time HT enabled
iwn0: received assoc_resp from 04:f0:21:17:40:ba rssi -21 mode 11g
iwn0: received msg 1/4 of the 4-way handshake from 04:f0:21:17:40:ba
iwn0: sending msg 2/4 of the 4-way handshake to 04:f0:21:17:40:ba
iwn0: received msg 3/4 of the 4-way handshake from 04:f0:21:17:40:ba
iwn0: sending msg 4/4 of the 4-way handshake to 04:f0:21:17:40:ba

iwn0: flags=208847 mtu 1500
lladdr 6c:88:14:36:27:b0
index 2 priority 4 llprio 3
groups: wlan egress
media: IEEE802.11 autoselect mode 11n (HT-MCS2 mode 11n)
status: active
ieee80211: nwid TEST chan 1 bssid 04:f0:21:17:40:ba -20dBm wpakey XXX 
wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp

Unfortunately the throughput is very low, only ~7 MBit. With mode 11g I get ~16 
MBit.


zarathustra:~# tcpbench apu01
  elapsed_ms  bytes mbps   bwidth
1004 7482725.962  100.00%
Conn:   1 Mbps:5.962 Peak Mbps:5.962 Avg Mbps:5.962
2007 8396646.697  100.00%
Conn:   1 Mbps:6.697 Peak Mbps:6.697 Avg Mbps:6.697
3010 8182446.533  100.00%
Conn:   1 Mbps:6.533 Peak Mbps:6.697 Avg Mbps:6.533
4013 9096367.255  100.00%
Conn:   1 Mbps:7.255 Peak Mbps:7.255 Avg Mbps:7.255
5014 8568006.848  100.00%
Conn:   1 Mbps:6.848 Peak Mbps:7.255 Avg Mbps:6.848
6015 8682246.946  100.00%
Conn:   1 Mbps:6.946 Peak Mbps:7.255 Avg Mbps:6.946
7021 8725086.945  100.00%
Conn:   1 Mbps:6.945 Peak Mbps:7.255 Avg Mbps:6.945
8023 8353806.670  100.00%
Conn:   1 Mbps:6.670 Peak Mbps:7.255 Avg Mbps:6.670
9025 8482326.779  100.00%
Conn:   1 Mbps:6.779 Peak Mbps:7.255 Avg Mbps:6.779
   10028 8439486.731  100.00%
Conn:   1 Mbps:6.731 Peak Mbps:7.255 Avg Mbps:6.731
   11036 8310966.596  100.00%
Conn:   1 Mbps:6.596 Peak Mbps:7.255 Avg Mbps:6.596

I'm now ready to test furhter.

Many thanks again!


Regards Uwe



Am 09.01.2017 13:54:55, schrieb Stefan Sperling:
> This diff adds 11n support to the athn(4) driver.
> Requires -current net80211 code from today.
> 
> Tested in hostap mode and client mode with:
> athn0 at pci1 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 16
> athn0: AR9280 rev 2 (2T2R), ROM rev 22, adddress xx:xx:xx:xx:xx:xx
> 
> And in client mode with:
> athn0 at uhub1 port 2 configuration 1 interface 0 "ATHEROS USB2.0 WLAN" rev 
> 2.00/1.08 addr 2
> athn0: AR9271 rev 1 (1T1R), ROM rev 13, address xx:xx:xx:xx:xx:xx
> 
> Hostap performance is not perfect yet but should be no worse than
> 11a/b/g modes in the same environment.
> 
> For Linux clients a fix for WME params is needed which I also posted to tech@.
> 
> This diff does not modify the known-broken and disabled ar9003 code,
> apart from making sure it still builds.
> 
> I'm looking 

Re: Support power saving with athn(4) in host AP mode

2012-11-12 Thread Uwe Werler
-Ursprüngliche Nachricht-
An: tech@openbsd.org; 
Von:Uwe Werler uwe.wer...@retiolum.eu
Gesendet:   Mo 12.11.2012 15:32
Betreff:Re: Support power saving with athn(4) in host AP mode
  Further testing would be welcome.  Even if you don't use clients with
  power saving enabled.  So if you're running an athn(4) based AP,
  please give this a spin.
  
 
 Runs like a charme with snapshot from 2012-11-11. Tried Windows 7, Android 
 ICS, 
 IPhone 3S, OpenBSD 4.7 and 5.2, Ubuntu 10.
 
 Thank You Mark for the excellent work!
 
 I replaced my existing AP with OpenBSD + Alix now and I'm happy.
 
 

add: I use a Wistron DNMA92 (miniPCI) / AR9280

athn0 at pci0 dev 12 function 0 Atheros AR9280 rev 0x01: irq 9
athn0: AR9280 rev 2 (2T2R), ROM rev 21, address a8:54:b2:3d:fd:a0