Re: cwm - Conf.bwidth vs cc->bwidth
On Sat 2013.01.05 at 14:50 +0100, Jan Stary wrote: > On Jan 04 23:27:48, h...@stare.cz wrote: > > Here's some more cleanage for cwm: > > the hmaximize and vmaximize functions are, obviously, completely dual, > > except that hmaximize uses Conf.bwidth when adjusting for a boundary, > > while vmaximize uses cc->bwidth (correctly IMHO). Committed, thanks. > Also, it seems that unmaximizing always sets cc->bwidth = Conf.bwidth > - there is cc->savegeom to restore from, but no cc->savewidth. Right. > Is that intentional? Do we want every window that returns from > a MAXIMIZED state to obtain the defalut bwidth, even if its width > has been changed in the meantime? Or has the "savebwidth" code > simply not been written yet? (and noting your other mail) there's no way to change a client's bwidth without a config change and subsequent restart; so using Conf.bwidth is OK. > Would it make sense to have cc->savewidth for that purpose, > or should that be another member of cc->savegeom ? Yes, we can save bwidth (probably in struct geom) as well as a host of other fields that could go into that same struct to reduce various other calculations. If 'bwidth' was the only thing that we reached back to Conf for, then I'd say sure, but it's not. Maybe it's worth it, maybe not - I don't know yet :) Cheers, Okan
Re: [PATCH] cwm - maximizing in each direction
* Jan Stary [130106 00:00]: > Below is a diff that enables cwm to maximize a window > in a given direction (left / right / up / down) only. > > Only left/right is implemented actually; I want to make sure > this isn't completely wrong before writing up the other half > (which will be dual of course). > > The motivating situation for me is that my usual X setup > is a vertically maximized xterm in the upper left corner > (to write what I am writing) and whatever accompanies it > (xdvi, firefox, mupdf, ...) in the rest of the screen. > Setting that up is not complicated, but maximizing the > other window to the "rest of the screen" means: > align its left border to the right border of the xterm, > then hold CMS-l until the window enlarges fully to the right. This sounds exactly like a problem solved by my tiling diff (vtile): https://github.com/polachok/cwm-openbsd/commit/514f44cdc994ed764e1fb9211edcbb8198da82c9 -- Alexander Polakov | plhk.ru
www/events.html future events year fix
Future events year should be 2013. -- James Turner | 0x560B0C49 --- events.html.origSat Jan 5 14:53:23 2013 +++ events.html Sat Jan 5 14:52:15 2013 @@ -38,7 +38,7 @@ like-minded people. Future events: -2012 +2013
[PATCH] cwm - maximizing in each direction
Below is a diff that enables cwm to maximize a window
in a given direction (left / right / up / down) only.
Only left/right is implemented actually; I want to make sure
this isn't completely wrong before writing up the other half
(which will be dual of course).
The motivating situation for me is that my usual X setup
is a vertically maximized xterm in the upper left corner
(to write what I am writing) and whatever accompanies it
(xdvi, firefox, mupdf, ...) in the rest of the screen.
Setting that up is not complicated, but maximizing the
other window to the "rest of the screen" means:
align its left border to the right border of the xterm,
then hold CMS-l until the window enlarges fully to the right.
Obviously, the obligate h/j/k/l keys are taken already,
so I chose (CM-) the arrows for the default keybindings.
In the current implementation of e.g. hmaximize,
it is checked whether this actually means full maximization.
As there are currently only two parts of full maximization
(CLIENT_HMAXIMIZED, CLIENT_VMAXIMIZED) it is done by checking
the other one. With four parts of maximization now, I have
used a macro (LASTMAX) instead that checks whether this is
the last bit that's missing in full maximization. I believe
the current [vh]maximizing function should be so altered too.
Xinerama considerations: first of all, I only have one monitor,
so could please someone with more screens test this?
My logic of placing the maximized window is obvious:
when left-maximizing, the new left border is the left border of
the screen where the current left border is; that is, the leftmost
screen which is 'hit' by the current window is where the left-maximization
happens. I believe this is the sensible thing. Similarly for right.
This differs from the logic currently implemented in the maximizing
functions: the screen holding the center of the window is found,
and the window is maximized within that screen. I object to this,
with the following counterexample in mind: with 3 screens,
and a window spanning a little more than the central screen,
"maximizing" it actually means shrinking it!
This difference in placement logic is what stops me from
replacing hmaximize with a call to lmaximize and rmaximize.
Comments?
Jan
Index: calmwm.h
===
RCS file: /cvs/xenocara/app/cwm/calmwm.h,v
retrieving revision 1.185
diff -u -p -r1.185 calmwm.h
--- calmwm.h4 Jan 2013 16:30:03 - 1.185
+++ calmwm.h5 Jan 2013 18:52:35 -
@@ -148,15 +148,22 @@ struct client_ctx {
int xproto;
#define CLIENT_HIDDEN 0x0001
#define CLIENT_IGNORE 0x0002
-#define CLIENT_VMAXIMIZED 0x0004
-#define CLIENT_HMAXIMIZED 0x0008
#define CLIENT_FREEZE 0x0010
#define CLIENT_GROUP 0x0020
#define CLIENT_UNGROUP 0x0040
+#define CLIENT_LMAXIMIZED 0x0100
+#define CLIENT_RMAXIMIZED 0x0200
+#define CLIENT_UMAXIMIZED 0x0400
+#define CLIENT_DMAXIMIZED 0x0800
#define CLIENT_HIGHLIGHT (CLIENT_GROUP | CLIENT_UNGROUP)
-#define CLIENT_MAXFLAGS(CLIENT_VMAXIMIZED |
CLIENT_HMAXIMIZED)
+#define CLIENT_HMAXIMIZED (CLIENT_LMAXIMIZED | CLIENT_RMAXIMIZED)
+#define CLIENT_VMAXIMIZED (CLIENT_UMAXIMIZED | CLIENT_DMAXIMIZED)
#define CLIENT_MAXIMIZED (CLIENT_VMAXIMIZED | CLIENT_HMAXIMIZED)
+#define CLIENT_MAXFLAGS(CLIENT_MAXIMIZED)
+#define LASTMAX(f, b) (((f | b) & CLIENT_MAXFLAGS) \
+ == CLIENT_MAXIMIZED)
+
int flags;
int state;
int active;
@@ -315,6 +322,7 @@ void client_cycle(struct screen_ctx
*
voidclient_cycle_leave(struct screen_ctx *,
struct client_ctx *);
voidclient_delete(struct client_ctx *);
+voidclient_dmaximize(struct client_ctx *);
voidclient_draw_border(struct client_ctx *);
struct client_ctx *client_find(Window);
voidclient_freeze(struct client_ctx *);
@@ -322,6 +330,7 @@ void client_getsizehints(struct
clien
voidclient_hide(struct client_ctx *);
voidclient_hmaximize(struct client_ctx *);
voidclient_leave(struct client_ctx *);
+voidclient_lmaximize(struct client_ctx *);
voidclient_lower(struct client_ctx *);
voidclient_map(struct client_ctx *);
voidclient_maximize(struct client_ctx *);
@@ -331,11 +340,13 @@ void client_ptrsave(struct
client_ctx
voidclient_ptrwarp(struct
Fix installboot messages (amd64, i386)
On x86:
$ /usr/mdec/installboot -n -v /boot /usr/mdec/biosboot sd0
boot: /boot proto: /usr/mdec/biosboot device: /dev/rsd0c
/boot is 5 blocks x 16384 bytes
fs block shift 2; part offset 63; inode block 112, offset 3496
master boot record (MBR) at sector 0
partition 3: type 0xA6 offset 63 size 293041602
/boot will be written at sector 63
That last line is misleading. It is biosboot that is written to
sector 63, not /boot. While there, I noticed that loadproto() also
puts the wrong file into some error messages.
ok?
Index: arch/amd64/stand/installboot/installboot.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/installboot/installboot.c,v
retrieving revision 1.24
diff -u -p -r1.24 installboot.c
--- arch/amd64/stand/installboot/installboot.c 13 Nov 2011 14:52:30 -
1.24
+++ arch/amd64/stand/installboot/installboot.c 5 Jan 2013 18:09:55 -
@@ -235,7 +235,7 @@ write_bootblocks(int devfd, struct diskl
/*
* Find OpenBSD partition. Floppies are special, getting an
-* everything-in-one /boot starting at sector 0.
+* everything-in-one biosboot starting at sector 0.
*/
if (dl->d_type != DTYPE_FLOPPY) {
start = findopenbsd(devfd, dl);
@@ -244,11 +244,12 @@ write_bootblocks(int devfd, struct diskl
}
if (verbose)
- fprintf(stderr, "/boot will be written at sector %u\n", start);
+ fprintf(stderr, "%s will be written at sector %u\n", proto,
+ start);
if (start + (protosize / dl->d_secsize) > BOOTBIOS_MAXSEC)
- warnx("/boot extends beyond sector %u. OpenBSD might not boot.",
- BOOTBIOS_MAXSEC);
+ warnx("%s extends beyond sector %u. OpenBSD might not boot.",
+ proto, BOOTBIOS_MAXSEC);
if (!nowrite) {
if (lseek(devfd, (off_t)start * dl->d_secsize, SEEK_SET) < 0)
@@ -352,7 +353,7 @@ loadproto(char *fname, long *size)
if (!IS_ELF(eh))
errx(1, "%s: bad magic: 0x%02x%02x%02x%02x",
- boot,
+ fname,
eh.e_ident[EI_MAG0], eh.e_ident[EI_MAG1],
eh.e_ident[EI_MAG2], eh.e_ident[EI_MAG3]);
@@ -365,7 +366,7 @@ loadproto(char *fname, long *size)
/* Program load header. */
if (eh.e_phnum != 1)
errx(1, "%s: %u ELF load sections (only support 1)",
- boot, eh.e_phnum);
+ fname, eh.e_phnum);
phsize = eh.e_phnum * sizeof(Elf_Phdr);
ph = malloc(phsize);
@@ -375,7 +376,7 @@ loadproto(char *fname, long *size)
lseek(fd, eh.e_phoff, SEEK_SET);
if (read(fd, ph, phsize) != phsize)
- errx(1, "%s: can't read header", boot);
+ errx(1, "%s: can't read header", fname);
tdsize = ph->p_filesz;
Index: arch/i386/stand/installboot/installboot.c
===
RCS file: /cvs/src/sys/arch/i386/stand/installboot/installboot.c,v
retrieving revision 1.67
diff -u -p -r1.67 installboot.c
--- arch/i386/stand/installboot/installboot.c 13 Nov 2011 14:52:30 -
1.67
+++ arch/i386/stand/installboot/installboot.c 5 Jan 2013 18:17:02 -
@@ -231,7 +231,7 @@ write_bootblocks(int devfd, struct diskl
/*
* Find OpenBSD partition. Floppies are special, getting an
-* everything-in-one /boot starting at sector 0.
+* everything-in-one biosboot starting at sector 0.
*/
if (dl->d_type != DTYPE_FLOPPY) {
start = findopenbsd(devfd, dl);
@@ -240,11 +240,12 @@ write_bootblocks(int devfd, struct diskl
}
if (verbose)
- fprintf(stderr, "/boot will be written at sector %u\n", start);
+ fprintf(stderr, "%s will be written at sector %u\n", proto,
+ start);
if (start + (protosize / dl->d_secsize) > BOOTBIOS_MAXSEC)
- warnx("/boot extends beyond sector %u. OpenBSD might not boot.",
- BOOTBIOS_MAXSEC);
+ warnx("%s extends beyond sector %u. OpenBSD might not boot.",
+ proto, BOOTBIOS_MAXSEC);
if (!nowrite) {
if (lseek(devfd, (off_t)start * dl->d_secsize, SEEK_SET) < 0)
@@ -348,7 +349,7 @@ loadproto(char *fname, long *size)
if (!IS_ELF(eh))
errx(1, "%s: bad magic: 0x%02x%02x%02x%02x",
- boot,
+ fname,
eh.e_ident[EI_MAG0], eh.e_ident[EI_MAG1],
eh.e_ident[EI_MAG2], eh.e_ident[EI_MAG3]);
@@ -361,7 +362,7 @@ loadproto(char *fname, long *size)
/* Program load header. */
if (eh.e_phnum != 1)
errx(1, "%s: %u ELF load sections (only support 1)",
- boot, eh.e_phnum);
+ fname, eh.e_phnum);
Patch for pcidevs
Hi Here is a diff for all but one of the unknown devices for the VIA VX900 chipset. A few questions: 1. Some devices were already listed as for the VX800, should these be changed to identify as say VX800/VX900? And same for some support chips that have been integrated into the VX900 - the USB host controller interfaces. 2. Some of the devices have specific functions that don't match any other in the list of VIA devices so I have left with the generic VX900 Host, should I go the whole hog and give specific names to them? 3. I assume someone else will crank the handle to regenerate pcidevs.h and pcidevs_data.h so haven't included diffs for them, is that the normal procedure? TTFN -- Mike Index: pcidevs === RCS file: /cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.1664 diff -u -p -r1.1664 pcidevs --- pcidevs 2 Jan 2013 05:45:41 - 1.1664 +++ pcidevs 5 Jan 2013 15:45:27 - @@ -5733,6 +5733,7 @@ product VIATECH VT3351_HB 0x0351 VT3351 product VIATECH VX800_00x0353 VX800 Host product VIATECH P4M900 0x0364 P4M900 Host product VIATECH VT8371_HB 0x0391 VT8371 Host +product VIATECH VX900_00x0410 VX900 Host product VIATECH VT6415 0x0415 VT6415 IDE product VIATECH VT8501 0x0501 VT8501 product VIATECH VT82C505 0x0505 VT82C505 @@ -5770,6 +5771,7 @@ product VIATECH K8M890_1 0x1336 K8M890 H product VIATECH VT3351_2 0x1351 VT3351 Host product VIATECH VX800_10x1353 VX800 Host product VIATECH P4M900_1 0x1364 P4M900 Host +product VIATECH VX900_ERRS 0x1410 VX900 Errors product VIATECH VT82C416 0x1571 VT82C416 IDE product VIATECH VT82C1595 0x1595 VT82C1595 PCI product VIATECH K8M800_2 0x2204 K8M800 Host @@ -5786,6 +5788,7 @@ product VIATECH K8M890_2 0x2336 K8M890 H product VIATECH VT3351_3 0x2351 VT3351 Host product VIATECH VX800_20x2353 VX800 Host product VIATECH P4M900_2 0x2364 P4M900 Host +product VIATECH VX900_20x2410 VX900 Host product VIATECH VT8251_PCI 0x287a VT8251 PCI product VIATECH VT8251_PCIE_0 0x287b VT8251 PCIE product VIATECH VT8251_PCIE_1 0x287c VT8251 PCIE @@ -5859,6 +5862,7 @@ product VIATECH CHROME9_HC0x3371 Chrome product VIATECH VT8237S_ISA0x3372 VT8237S ISA product VIATECH VT8237A_PPB_1 0x337a VT8237A PCI-PCI product VIATECH VT8237A_PPB_2 0x337b VT8237A PCI-PCI +product VIATECH VX900_DRAM 0x3410 VX900 DRAM product VIATECH K8M800_4 0x4204 K8M800 Host product VIATECH K8T890_4 0x4238 K8T890 Host product VIATECH PT880_40x4258 PT880 Host @@ -5873,6 +5877,7 @@ product VIATECH K8M890_4 0x4336 K8M890 H product VIATECH VT3351_5 0x4351 VT3351 Host product VIATECH VX800_40x4353 VX800 Host product VIATECH P4M900_4 0x4364 P4M900 Host +product VIATECH VX900_PMC 0x4410 VX900 PMC product VIATECH K8T890_IOAPIC 0x5238 K8T890 IOAPIC product VIATECH PT894_IOAPIC 0x5308 PT894 IOAPIC product VIATECH CX700_IDE 0x5324 CX700 IDE @@ -5883,6 +5888,7 @@ product VIATECH VT3351_IOAPIC 0x5351 VT3 product VIATECH VX800_IOAPIC 0x5353 VX800 IOAPIC product VIATECH P4M900_IOAPIC 0x5364 P4M900 IOAPIC product VIATECH VT8237S_SATA 0x5372 VT8237S SATA +product VIATECH VX900_IOAPIC 0x5410 VX900 IOAPIC product VIATECH RHINEII0x6100 RhineII product VIATECH VT3351_6 0x6238 VT3351 Host product VIATECH VT8251_AHCI0x6287 VT8251 AHCI @@ -5890,6 +5896,8 @@ product VIATECH K8M890_6 0x6290 K8M890 H product VIATECH P4M890_6 0x6327 P4M890 Security product VIATECH VX800_60x6353 VX800 Host product VIATECH P4M900_6 0x6364 P4M900 Security +product VIATECH VX900_60x6410 VX900 Host +product VIATECH CHROME9HD 0x7122 Chrome9 HD IGP product VIATECH K8M800_7 0x7204 K8M800 Host product VIATECH VT8378_VGA 0x7205 VT8378 VGA product VIATECH PT894_50x7308 PT894 Host @@ -5905,6 +5913,7 @@ product VIATECH K8HTB_7 0x7282 K8HTB Ho product VIATECH CN700_70x7314 CN700 Host product VIATECH CX700_70x7324 CX700 Host product VIATECH VT3351_7 0x7351 VT3351 Host +product VIATECH VX900_70x7410 VX900 Host product VIATECH VT8231_ISA 0x8231 VT8231 ISA product VIATECH VT8231_PWR 0x8235 VT8231 PMG product VIATECH VT8363_AGP 0x8305 VT8363 AGP @@ -5912,6 +5921,7 @@ product VIATECH CX700_ISA 0x8324 CX700 I product VIATECH VX800_ISA 0x8353 VX800 ISA product VIATECH VT8371_PPB 0x8391 VT8371 PCI-PCI product VIATECH VX855_ISA 0x8409 VX855 ISA +product VIATECH VX900_80x8410 VX900 Host product VIATECH VT8501_AGP 0x8501 VT8501 AGP product VIATECH VT82C597AGP0x8597 VT82C597 AGP product VIATECH VT82C
socket splicing for UDP
Hi,
Here is my kernel diff to expand socket splicing to UDP. The
advantage for relaying applications is that they can forward the
data without copying it to user space. Currently relayd uses socket
splicing for TCP connections only.
The idea of my implementation is to merge the code relevant for UDP
from sosend() and soreceive() into somove(). That allows the kernel
to directly transfer the UDP data from one socket to another.
I have written a bunch of tests in /usr/src/regress/sys/kern/sosplice/udp/.
Performance measurement and a real live relaying daemon are on my
todo list.
bluhm
Index: kern/uipc_socket.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.110
diff -u -p -r1.110 uipc_socket.c
--- kern/uipc_socket.c 31 Dec 2012 13:46:49 - 1.110
+++ kern/uipc_socket.c 4 Jan 2013 17:19:51 -
@@ -1042,7 +1042,8 @@ sosplice(struct socket *so, int fd, off_
return (EPROTONOSUPPORT);
if (so->so_options & SO_ACCEPTCONN)
return (EOPNOTSUPP);
- if ((so->so_state & (SS_ISCONNECTED|SS_ISCONNECTING)) == 0)
+ if ((so->so_state & (SS_ISCONNECTED|SS_ISCONNECTING)) == 0 &&
+ (so->so_proto->pr_flags & PR_CONNREQUIRED))
return (ENOTCONN);
/* If no fd is given, unsplice by removing existing link. */
@@ -1070,6 +1071,10 @@ sosplice(struct socket *so, int fd, off_
return (error);
sosp = fp->f_data;
+ if (so->so_state & SS_ISCONFIRMING)
+ (*so->so_proto->pr_usrreq)(so, PRU_RCVD, NULL, NULL, NULL,
+ curproc);
+
/* Lock both receive and send buffer. */
if ((error = sblock(&so->so_rcv,
(so->so_state & SS_NBIO) ? M_NOWAIT : M_WAITOK)) != 0) {
@@ -1159,6 +1164,7 @@ somove(struct socket *so, int wait)
splsoftassert(IPL_SOFTNET);
+ nextpkt:
if (so->so_error) {
error = so->so_error;
goto release;
@@ -1175,9 +1181,7 @@ somove(struct socket *so, int wait)
goto release;
/* Calculate how many bytes can be copied now. */
- len = so->so_rcv.sb_cc;
- if (len == 0)
- goto release;
+ len = so->so_rcv.sb_datacc;
if (so->so_splicemax) {
KASSERT(so->so_splicelen < so->so_splicemax);
if (so->so_splicemax <= so->so_splicelen + len) {
@@ -1201,13 +1205,78 @@ somove(struct socket *so, int wait)
}
sosp->so_state |= SS_ISSENDING;
- /* Take at most len mbufs out of receive buffer. */
+ SBLASTRECORDCHK(&so->so_rcv, "somove 1");
+ SBLASTMBUFCHK(&so->so_rcv, "somove 1");
m = so->so_rcv.sb_mb;
+ if (m == NULL)
+ goto release;
nextrecord = m->m_nextpkt;
- for (off = 0, mp = &m; off < len;
+
+ /* Drop address and control information not used with splicing. */
+ if (so->so_proto->pr_flags & PR_ADDR) {
+#ifdef DIAGNOSTIC
+ if (m->m_type != MT_SONAME)
+ panic("somove soname");
+#endif
+ m = m->m_next;
+ }
+ while (m && m->m_type == MT_CONTROL) {
+ m = m->m_next;
+ }
+ if (m == NULL) {
+ sbdroprecord(&so->so_rcv);
+ if (so->so_proto->pr_flags & PR_WANTRCVD && so->so_pcb)
+ (so->so_proto->pr_usrreq)(so, PRU_RCVD, NULL,
+ (struct mbuf *)0L, NULL, NULL);
+ goto nextpkt;
+ }
+
+ if (so->so_proto->pr_flags & PR_ATOMIC) {
+ if ((m->m_flags & M_PKTHDR) == 0)
+ panic("somove pkthdr");
+ if (sosp->so_snd.sb_hiwat < m->m_pkthdr.len) {
+ error = EMSGSIZE;
+ goto release;
+ }
+ if (len < m->m_pkthdr.len)
+ goto release;
+ if (m->m_pkthdr.len < len) {
+ maxreached = 0;
+ len = m->m_pkthdr.len;
+ }
+ /*
+* Throw away the name mbuf after it has been assured
+* that the whole first record can be processed.
+*/
+ m = so->so_rcv.sb_mb;
+ sbfree(&so->so_rcv, m);
+ MFREE(m, so->so_rcv.sb_mb);
+ sbsync(&so->so_rcv, nextrecord);
+ }
+ /*
+* Throw away the control mbufs after it has been assured
+* that the whole first record can be processed.
+*/
+ m = so->so_rcv.sb_mb;
+ while (m && m->m_type == MT_CONTROL) {
+ sbfree(&so->so_rcv, m);
+ MFREE(m, so->so_rcv.sb_mb);
+ m = so->so_rcv.sb_mb;
+ sbsync(&so->so_rcv, nextrecord);
+ }
+
+ SBLASTRECORDCHK(&so->so_rcv, "somove 2");
+ SBLASTMBUFCHK(&so->so_rcv, "somove 2");
+
+
Re: cwm - Conf.bwidth vs cc->bwidth
On Jan 05 14:50:21, h...@stare.cz wrote: > On Jan 04 23:27:48, h...@stare.cz wrote: > > Here's some more cleanage for cwm: > > the hmaximize and vmaximize functions are, obviously, completely dual, > > except that hmaximize uses Conf.bwidth when adjusting for a boundary, > > while vmaximize uses cc->bwidth (correctly IMHO). > > Also, it seems that unmaximizing always sets cc->bwidth = Conf.bwidth > - there is cc->savegeom to restore from, but no cc->savewidth. Please ignore - there is no way to change the borderwidth to something else then what we have started with in the config, right?
Re: cwm - Conf.bwidth vs cc->bwidth
On Jan 04 23:27:48, h...@stare.cz wrote:
> Here's some more cleanage for cwm:
> the hmaximize and vmaximize functions are, obviously, completely dual,
> except that hmaximize uses Conf.bwidth when adjusting for a boundary,
> while vmaximize uses cc->bwidth (correctly IMHO).
Also, it seems that unmaximizing always sets cc->bwidth = Conf.bwidth
- there is cc->savegeom to restore from, but no cc->savewidth.
Is that intentional? Do we want every window that returns from
a MAXIMIZED state to obtain the defalut bwidth, even if its width
has been changed in the meantime? Or has the "savebwidth" code
simply not been written yet?
Would it make sense to have cc->savewidth for that purpose,
or should that be another member of cc->savegeom ?
(I always use 1px borders anyway, but it feels a bit
inconsitent to restore all of the geometry/position
but not the border width.)
> Jan
>
>
> Index: client.c
> ===
> RCS file: /cvs/xenocara/app/cwm/client.c,v
> retrieving revision 1.115
> diff -u -p -r1.115 client.c
> --- client.c 4 Jan 2013 16:30:03 - 1.115
> +++ client.c 4 Jan 2013 22:21:29 -
> @@ -321,7 +321,7 @@ client_vmaximize(struct client_ctx *cc)
>
> /* if this will make us fully maximized then remove boundary */
> if ((cc->flags & CLIENT_MAXFLAGS) == CLIENT_HMAXIMIZED) {
> - cc->geom.w += Conf.bwidth * 2;
> + cc->geom.w += cc->bwidth * 2;
> cc->bwidth = 0;
> }
