Re: [diff] lpbl(4): driver for TI LP8550 backlight controller (found in e.g. MacBook Air 6,2)
On Sun, 10 Jan 2016 21:28:31 +0100 Joerg Jung wrote:
> On Sun, Jan 10, 2016 at 04:59:22AM +0200, Sviatoslav Chagaev wrote:
> > So below is a driver for TI LP8550.
...
> > If there's any chance for it to be commited, please tell me what I need to
> > fix/improve to get it commited (so I don't have to reapply it every time I
> > upgrade).
>
> IMHO, instead of adding another driver to the mix, I would prefer this
> to be handled through the associated asmc(4) keys instead of accessing
> the chip directly. The SMC is supposed to be the central point for such
> manipulations. Unfortunately, the keys are not documented and need some
> non-trivial effort to be figured out.
>
> If this is not possible through asmc(4) and if your new driver improves
> the situation then I'm fine with importing it, but for now it is just
> worse.
>
Using knowledge acquired from [1] and [2] made a diff, posted below for
reference, which adds:
* ioctl interface to asmc(4) to allow reading/writing of ``keys'' from
userspace;
* companion smcprobe(1) which reads/writes ``keys'' using the ioctl;
* smcdumpkeys(1): scans an SMC textual firmware file and dumps the ``key''
table that it contains.
Downloaded SMC FW [3], unpacked it using Google Drive and used smcdumpkeys(1) +
smcprobe(1) to create the table of keys and their current values before suspend
[4] and after wake up [5]. Diffed them [6], filtering out keys which change over
time as they are probably sensors (some might have gotten through).
Tried modifying all keys whose names start with 'B': no effect.
Tried modifying keys which are different after wake up: no effect.
[1]
https://reverse.put.as/wp-content/uploads/2015/12/D1_02_Alex_Ninjas_and_Harry_Potter.pdf
[2]
https://dev.inversepath.com/download/public/embedded_systems_exploitation.pdf
[3] https://support.apple.com/kb/DL1748?locale=en_US
[4] https://gist.github.com/S010/26145f4446fcc0b8a0d6#file-before_suspend-txt
[5] https://gist.github.com/S010/26145f4446fcc0b8a0d6#file-after_wakeup-txt
[6]
https://gist.github.com/S010/26145f4446fcc0b8a0d6#file-suspend_wakeup_key-diff
Index: sys/dev/isa/asmc.c
===
RCS file: /cvs/src/sys/dev/isa/asmc.c,v
retrieving revision 1.28
diff -u -p -r1.28 asmc.c
--- sys/dev/isa/asmc.c 27 Dec 2015 20:54:53 - 1.28
+++ sys/dev/isa/asmc.c 27 Jan 2016 02:43:15 -
@@ -26,6 +26,8 @@
#include
#include
#include
+#include
+#include
#include
@@ -705,4 +707,47 @@ asmc_update(void *arg)
if (!(sc->sc_sensor_motion[i].flags & SENSOR_FINVALID))
asmc_motion(sc, i, 0);
#endif
+}
+
+int
+asmcopen(dev_t dev, int flag, int mode, struct proc *p)
+{
+ /* FIXME */
+ return 0;
+}
+
+int
+asmcclose(dev_t dev, int flag, int mode, struct proc *p)
+{
+ /* FIXME */
+ return 0;
+}
+
+/*
+ * An ioctl interface to poke SMC ``keys'' from userspace.
+ */
+int
+asmcioctl(dev_t dev, u_long cmd, caddr_t addr, int flag, struct proc *p)
+{
+ struct asmc_softc *sc;
+ struct asmc_key_buf *buf = (struct asmc_key_buf *)addr;
+ int error;
+
+ sc = asmc_cd.cd_devs[minor(dev)];
+
+ switch (cmd) {
+ case ASMC_READ_KEY:
+ error = asmc_try(sc, ASMC_READ, buf->key, buf->data, buf->len);
+ break;
+ case ASMC_WRITE_KEY:
+ error = asmc_try(sc, ASMC_WRITE, buf->key, buf->data, buf->len);
+ break;
+ default:
+ return ENOTTY;
+ }
+
+ if (error)
+ return EIO;
+ else
+ return 0;
}
Index: sys/dev/isa/asmc.h
===
RCS file: sys/dev/isa/asmc.h
diff -N sys/dev/isa/asmc.h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sys/dev/isa/asmc.h 27 Jan 2016 02:43:15 -
@@ -0,0 +1,32 @@
+/*
+ * Copyright (c) 2016 Sviatoslav Chagaev <sviatoslav.chag...@gmail.com>
+ *
+ * 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.
+ */
+
+#ifndef _ASMC_H_
+#define _ASMC_H_
+
+#include
+#include
+
+struct asmc_key_buf {
+ char key[4];
+ size_t len;
+ uint8_t data[32];
+};
+
+#define ASMC_R
Re: [diff] lpbl(4): driver for TI LP8550 backlight controller (found in e.g. MacBook Air 6,2)
On Tue, 12 Jan 2016 01:37:39 +0200
Sviatoslav Chagaev <sviatoslav.chag...@gmail.com> wrote:
> On Sun, 10 Jan 2016 21:28:31 +0100
> Joerg Jung <m...@umaxx.net> wrote:
> > On Sun, Jan 10, 2016 at 04:59:22AM +0200, Sviatoslav Chagaev wrote:
> >
> > > An Intel developer claims [2] that it's not a bug in Intel KMS driver and
> > > people
> > > claim [3] the problem goes away when booting in legacy BIOS mode.
> >
> > That makes no sense to me. If the problem goes aways when booting
> > legacy BIOS, so it must be a bug when not, right?
>
> Judging by the code at e.g. sys/dev/pci/drm/i915/intel_panel.c:984, it
> seems Intel KMS driver expects BIOS or EFI to configure backlight,
> then reads these values and uses them itself.
>
> I found documentation for Intel Haswell [1] and glanced over
> descriptions of relevant registers (BLC_PWM_CTL, BLC_PWM2_CTL,
> BLC_PWM_DATA, BLC_MISC_CTL, BLM_HIST_CTL, BLM_HIST_BIN, BLM_HIST_GUARD,
> UTIL_PIN_CTL, SBLC_PWM_CTL1, SBLC_PWM_CTL2), they are confusing...
>
> Based on these, I agree, it might be a bug in Intel KMS.
>
> I'll add debug prints and play with these registers, maybe I'll spot
> some incorrect values.
>
> [1]
> https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-hsw-commandreference-registers_0_0.pdf
>
Had no luck with Intel KMS:
Added register dump to every backlight operation, see first diff.
State of registers I get from EFI:
pch_dump_backlight_registers(): pch_setup_backlight
MY_BLC_PWM_CTL= 0x; MY_BLC_PWM_DATA = 0x
MY_BLC_PWM_DATA2 = 0x; MY_BLM_HIST_CTL = 0x
MY_BLM_HIST_BIN = 0x; MY_BLM_HIST_GUARD = 0x
MY_BLC_PWM2_CTL = 0x6000; MY_BLC_MISC_CTL = 0x
MY_UTIL_PIN_CTL = 0x; MY_SBLC_PWM_CTL1 = 0xc000
MY_SBLC_PWM_CTL2 = 0x0ad901c3;
State of registers after Intel KMS configures them:
pch_dump_backlight_registers(): pch_set_backlight
MY_BLC_PWM_CTL= 0xe000; MY_BLC_PWM_DATA = 0x0ad9
MY_BLC_PWM_DATA2 = 0x; MY_BLM_HIST_CTL = 0x0006
MY_BLM_HIST_BIN = 0x; MY_BLM_HIST_GUARD = 0x
MY_BLC_PWM2_CTL = 0x6000; MY_BLC_MISC_CTL = 0x
MY_UTIL_PIN_CTL = 0x; MY_SBLC_PWM_CTL1 = 0x8000
MY_SBLC_PWM_CTL2 = 0x0ad9;
BLC_PWM_CTL change seems strange.
Modified pch_*_backlight() functions so they do not change the
configuration set by EFI, see second diff, but observed no change in
behaviour.
Index: sys/dev/pci/drm/i915/i915_reg.h
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_reg.h,v
retrieving revision 1.11
diff -u -p -r1.11 i915_reg.h
--- sys/dev/pci/drm/i915/i915_reg.h 25 Sep 2015 16:15:19 - 1.11
+++ sys/dev/pci/drm/i915/i915_reg.h 12 Jan 2016 02:54:49 -
@@ -2493,6 +2493,18 @@
#define BACKLIGHT_DUTY_CYCLE_MASK_PNV(0xfffe)
#define BLM_POLARITY_PNV (1 << 0) /* pnv only */
+#define MY_BLC_PWM_CTL 0x48250
+#define MY_BLC_PWM_DATA0x48254
+#define MY_BLC_PWM_DATA2 0x48354
+#define MY_BLM_HIST_CTL0x48260
+#define MY_BLM_HIST_BIN0x48264
+#define MY_BLM_HIST_GUARD 0x48268
+#define MY_BLC_PWM2_CTL0x48350
+#define MY_BLC_MISC_CTL0x48360
+#define MY_UTIL_PIN_CTL0x48400
+#define MY_SBLC_PWM_CTL1 0xc8250
+#define MY_SBLC_PWM_CTL2 0xc8254
+
#define BLC_HIST_CTL (dev_priv->info->display_mmio_offset + 0x61260)
/* New registers for PCH-split platforms. Safe where new bits show up, the
Index: sys/dev/pci/drm/i915/intel_panel.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/intel_panel.c,v
retrieving revision 1.11
diff -u -p -r1.11 intel_panel.c
--- sys/dev/pci/drm/i915/intel_panel.c 23 Sep 2015 23:12:12 - 1.11
+++ sys/dev/pci/drm/i915/intel_panel.c 12 Jan 2016 02:54:49 -
@@ -36,6 +36,38 @@
#define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
+void pch_dump_backlight_registers(struct intel_connector *connector, const
char *msg)
+{
+ struct drm_device *dev = connector->base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ u32 i = 0;
+ u32 value;
+
+ printf("%s(): %s\n", __func__, msg);
+
+#define Y(register)\
+ value = I915_READ(register);\
+ printf("%-17s = 0x%08x%s", \
+ #register, value, (i++ & 1) ? "\n" : "; ");
+
+ Y(MY_BLC_PWM_CTL);
+ Y(MY_BLC_PWM_DATA);
+ Y(MY_BLC_PWM_DATA2);
+ Y(MY_BLM_HIST_CTL);
+ Y(MY_BLM_HIST_BIN);
+ Y(MY_BLM_HIST_GUARD);
+ Y(MY_BLC_PWM2_CT
Re: [diff] lpbl(4): driver for TI LP8550 backlight controller (found in e.g. MacBook Air 6,2)
On Sun, 10 Jan 2016 21:28:31 +0100 Joerg Jung <m...@umaxx.net> wrote: > On Sun, Jan 10, 2016 at 04:59:22AM +0200, Sviatoslav Chagaev wrote: > > Hi, > > > > I'm running -current on Apple MacBook Air 6,2. I installed using Jasper's > > instructions [1], OpenBSD is the only OS and boots via EFI. > > > > I'm experiencing a problem with LCD backlight: on wakeup from suspend, the > > backlight brightness is not restored and becomes unadjustable. If adjusted > > down, > > it turns off, if adjusted up, it goes to 100%. > > I also own a MacBook Air 6,2 and wakeup does not really work at all for > me, as the screen just stays black. Basically I see the same as > reported in [5] for the MacBook Pro. Try the following: 1) Upgrade to latest snapshot. 2) Bind `wsconsctl display.brightness+=5` to some key combination in your X window manager. 3) On wake up, start adjusting the brightness up. At some magical point (something like 87% for me IIRC) you should observe the backlight turning on and going to 100% brightness. From this point, if you adjust down, the backlight turns off, if you adjust up, the backlight goes to 100%. If you don't observe this, we might be experiencing different issues. > > > An Intel developer claims [2] that it's not a bug in Intel KMS driver and > > people > > claim [3] the problem goes away when booting in legacy BIOS mode. > > That makes no sense to me. If the problem goes aways when booting > legacy BIOS, so it must be a bug when not, right? Judging by the code at e.g. sys/dev/pci/drm/i915/intel_panel.c:984, it seems Intel KMS driver expects BIOS or EFI to configure backlight, then reads these values and uses them itself. I found documentation for Intel Haswell [1] and glanced over descriptions of relevant registers (BLC_PWM_CTL, BLC_PWM2_CTL, BLC_PWM_DATA, BLC_MISC_CTL, BLM_HIST_CTL, BLM_HIST_BIN, BLM_HIST_GUARD, UTIL_PIN_CTL, SBLC_PWM_CTL1, SBLC_PWM_CTL2), they are confusing... Based on these, I agree, it might be a bug in Intel KMS. I'll add debug prints and play with these registers, maybe I'll spot some incorrect values. [1] https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-hsw-commandreference-registers_0_0.pdf > > > It turns out [4], a numbers of MacBook models [5], including mine, have a > > Texas > > Instruments LP8550 LED backlight controller on I2C bus. By default, it's > > controlled by external PWM. But it can be configured to be controlled by > > it's > > own internal register instead. > > > > So below is a driver for TI LP8550. > > > > With this driver, after wake up from suspend, the brightness level is > > restored > > and can be freely adjusted. > > I've tested the driver and while it compiles and attaches fine it does > not work for me. After switching to console the screen stays black. Yep, it needs to be integrated with Intel KMS to not break anything... > > > The catch is that Intel KMS driver seems to control the chip's ``EN'' pin > > (basically an on/off pin). So whenever Intel KMS toggles the backlight, > > namely > > on power management (e.g. `xset dpms force off`) and on Xorg <--> VT > > switch, > > the chip's brightness control register gets reset and you need to > > `wsconsctl display.backlight=` to turn the backlight back on. > > > > But it beats rebooting. > > Not for me, with my machine -current works better without your patch, > because I can switch from X to console and back and brightness is > correctly adjusted. > > > If there's any chance for it to be commited, please tell me what I need to > > fix/improve to get it commited (so I don't have to reapply it every time I > > upgrade). > > IMHO, instead of adding another driver to the mix, I would prefer this > to be handled through the associated asmc(4) keys instead of accessing > the chip directly. The SMC is supposed to be the central point for such > manipulations. Unfortunately, the keys are not documented and need some > non-trivial effort to be figured out. > > If this is not possible through asmc(4) and if your new driver improves > the situation then I'm fine with importing it, but for now it is just > worse. > > > Next step could be to somehow integrate it with Intel KMS. > > Yes, for me this is must-have before it can be committed. > > Some minor style comments on the code inline below. Thanks, if there will be a next version of this diff, I'll fix them.
[diff] lpbl(4): driver for TI LP8550 backlight controller (found in e.g. MacBook Air 6,2)
Hi, I'm running -current on Apple MacBook Air 6,2. I installed using Jasper's instructions [1], OpenBSD is the only OS and boots via EFI. I'm experiencing a problem with LCD backlight: on wakeup from suspend, the backlight brightness is not restored and becomes unadjustable. If adjusted down, it turns off, if adjusted up, it goes to 100%. An Intel developer claims [2] that it's not a bug in Intel KMS driver and people claim [3] the problem goes away when booting in legacy BIOS mode. It turns out [4], a numbers of MacBook models [5], including mine, have a Texas Instruments LP8550 LED backlight controller on I2C bus. By default, it's controlled by external PWM. But it can be configured to be controlled by it's own internal register instead. So below is a driver for TI LP8550. With this driver, after wake up from suspend, the brightness level is restored and can be freely adjusted. The catch is that Intel KMS driver seems to control the chip's ``EN'' pin (basically an on/off pin). So whenever Intel KMS toggles the backlight, namely on power management (e.g. `xset dpms force off`) and on Xorg <--> VT switch, the chip's brightness control register gets reset and you need to `wsconsctl display.backlight=` to turn the backlight back on. But it beats rebooting. If there's any chance for it to be commited, please tell me what I need to fix/improve to get it commited (so I don't have to reapply it every time I upgrade). Next step could be to somehow integrate it with Intel KMS. [1] https://blog.jasper.la/openbsd-uefi-bootloader-howto/ [2] https://bugs.freedesktop.org/show_bug.cgi?id=67454#c103 [3] https://bugs.freedesktop.org/show_bug.cgi?id=67454#c58 [4] https://bugs.freedesktop.org/show_bug.cgi?id=67454#c78 [5] http://marc.info/?l=openbsd-misc=144988400031788=2 Index: share/man/man4/iic.4 === RCS file: /cvs/src/share/man/man4/iic.4,v retrieving revision 1.84 diff -u -p -u -p -r1.84 iic.4 --- share/man/man4/iic.427 Dec 2014 16:08:03 - 1.84 +++ share/man/man4/iic.410 Jan 2016 01:52:55 - @@ -153,6 +153,8 @@ National Semiconductor LM87 temperature, National Semiconductor LM93 temperature, voltage, and fan sensor .It Xr lmtemp 4 National Semiconductor LM75/LM76/LM77 temperature sensor +.It Xr lpbl 4 +Texas Instruments LP8550 LED backlight controller .It Xr maxds 4 Maxim DS1624/DS1631/DS1721 temperature sensor .It Xr maxtmp 4 Index: share/man/man4/lpbl.4 === RCS file: share/man/man4/lpbl.4 diff -N share/man/man4/lpbl.4 --- /dev/null 1 Jan 1970 00:00:00 - +++ share/man/man4/lpbl.4 10 Jan 2016 01:52:55 - @@ -0,0 +1,48 @@ +.\" +.\" Copyright (c) 2016 Sviatoslav Chagaev <sviatoslav.chag...@gmail.com> +.\" +.\" 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. +.\" +.Dd $Mdocdate: January 7 2016 $ +.Dt LPBL 4 +.Os +.Sh NAME +.Nm lpbl +.Nd Texas Instruments LP8550 LED backlight controller +.Sh SYNOPSIS +.Cd "lpbl0 at iic?" +.Sh DESCRIPTION +The +.Nm +driver provides support for the LP8550 LED backlight controller, which can be +found in various models of Intel based Apple laptops. +.Pp +The driver allows to control the brightness of LCD backlight through +.Xr wsconsctl 8 +variable +.Va display.backlight . +.Sh SEE ALSO +.Xr intro 4 , +.Xr iic 4 , +.Xr wsconsctl 8 +.Sh HISTORY +The +.Nm +driver first appeared in +.Ox 5.9 . +.Sh AUTHORS +.An -nosplit +The +.Nm +driver was written by +.An Sviatoslav Chagaev Aq Mt sviatoslav.chag...@gmail.com . Index: sys/dev/i2c/files.i2c === RCS file: /cvs/src/sys/dev/i2c/files.i2c,v retrieving revision 1.51 diff -u -p -u -p -r1.51 files.i2c --- sys/dev/i2c/files.i2c 31 Mar 2013 13:30:24 - 1.51 +++ sys/dev/i2c/files.i2c 10 Jan 2016 01:52:58 - @@ -123,6 +123,11 @@ device glenv attach glenv at i2c file dev/i2c/gl518sm.c glenv +# Texas Instruments LP8550 LED backlight controller +device lpbl +attach lpbl at i2c +file dev/i2c/lp8550.clpbl +
ld.so: shared objects with same-name global function symbol
Hi,
I'm investigating Alf Schlichting's report [1] of regression in ld.so
caused by my diff [2]. This regression reproduces on amd64-current too.
I found errors in my diff which break the dlclose/test1/prog2 test. But
what's really interesting -- is the dlclose/test1/prog3 test.
I found that with current ld.so, dlclose/test1/prog3 works because the
libaa and libbb are loaded as a load group because there is an
explicit dependency from libaa to libbb. If, however, the dependency
between shared objects is removed, like in the diff below -- the test
crashes both with and without my diff:
=== dlclose/test1/prog4
./prog4
*** Signal SIGSEGV in dlclose/test1/prog4 (bsd.regress.mk:48
'run-regress-prog4')
FAILED
*** Error 1 in target 'regress' (ignored)
If we read the dynamic symbol tables of both libraries, here's what we
see:
$ readelf -sD libaa/libaa.so.1.0 libbb/libbb.so.1.0 | grep dup
31 34: 0bc0 3FUNC GLOBAL DEFAULT 8
duplicateFun
35 34: 0d10 6FUNC GLOBAL DEFAULT 8
duplicateFun
Both symbols are of function type and global binding.
Here's what SysV ABI [3] has to say regarding this about relocatable
objects:
When the link editor combines several relocatable object files,
it does not allow multiple definitions of STB_GLOBAL symbols with the
same name.
But I think it makes sense to not allow this for shared objects too.
How can one expect a program to work correctly if there is a
collision between two shared objects which is silently ignored? This
also seems like an illegitimate way to replace some functionality of
another lib with your own...
Do you agree that when there are shared objects which have global-bound
function symbols with the same name -- ld.so must not allow such a
program to run/dlopen said shared objects?
[1] http://marc.info/?l=openbsd-portsm=142901624010155w=2
[2] http://marc.info/?l=openbsd-bugsm=141653930524559w=2
[3] http://www.sco.com/developers/gabi/latest/ch4.symtab.html
Index: regress/libexec/ld.so/dlclose//test1/Makefile
===
RCS file: /cvs/src/regress/libexec/ld.so/dlclose/test1/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- regress/libexec/ld.so/dlclose//test1/Makefile 30 Sep 2005 15:16:18
- 1.2
+++ regress/libexec/ld.so/dlclose//test1/Makefile 7 May 2015 23:33:48
-
@@ -1,5 +1,5 @@
# $OpenBSD: Makefile,v 1.2 2005/09/30 15:16:18 kurt Exp $
-SUBDIR+= libbb libaa prog1 prog2 prog3
+SUBDIR+= libbb libaa libcc prog1 prog2 prog3 prog4
.include bsd.subdir.mk
Index: regress/libexec/ld.so/dlclose//test1/Makefile.inc
===
RCS file: /cvs/src/regress/libexec/ld.so/dlclose/test1/Makefile.inc,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile.inc
--- regress/libexec/ld.so/dlclose//test1/Makefile.inc 28 Sep 2005 15:42:32
- 1.1.1.1
+++ regress/libexec/ld.so/dlclose//test1/Makefile.inc 7 May 2015 23:33:48
-
@@ -17,3 +17,12 @@ BB_OBJDIR!= if [ -d $(BB_DIR)/${__objdir
else \
echo $(BB_DIR); \
fi
+
+CC_DIR=${.CURDIR}/../libcc
+
+CC_OBJDIR!=if [ -d $(CC_DIR)/${__objdir} ]; then \
+ echo $(CC_DIR)/${__objdir}; \
+ else \
+ echo $(CC_DIR); \
+ fi
+
--- /dev/null Fri May 8 02:41:30 2015
+++ regress/libexec/ld.so/dlclose/test1/libcc/Makefile Mon Apr 20 00:12:26 2015
@@ -0,0 +1,9 @@
+# $OpenBSD: Makefile,v 1.1.1.1 2005/09/28 15:42:32 kurt Exp $
+
+LIB= cc
+SRCS= cc.c
+LDADD+=-Wl,-E
+
+regress: all
+
+.include bsd.lib.mk
--- /dev/null Fri May 8 02:41:30 2015
+++ regress/libexec/ld.so/dlclose/test1/libcc/cc.c Mon Apr 20 00:10:51 2015
@@ -0,0 +1,25 @@
+/*
+ * Copyright (c) 2005 Kurt Miller k...@openbsd.org
+ *
+ * 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.
+ *
+ */
+
+int ccSymbol;
+
+int
+duplicateFun()
+{
+ return (0);
+}
+
--- /dev/null Fri May 8 02:41:30 2015
+++ regress/libexec/ld.so/dlclose/test1/libcc/shlib_version Mon Apr 20
00:11:10 2015
@@ -0,0 +1,2 @@
+major=1
+minor=0
---
local user can peek on key being set by ifconfig(8)
Hi, you can set various keys/passphrases using ifconfig(8), e.g. WPA key: # ifconfig iwn0 wpakey 'hunter2' The problem with that is that any local user can scan the process table and see this password. Here's a retarded shell script which continously scans the output of ps and prints out all ifconfig invocations and can be used to peek on keys: #!/bin/sh last_pid= while true; do pid=$(pgrep -u 0 ifconfig) if [ $pid ] [ $pid != $last_pid ]; then ps -p $pid last_pid=$pid fi done I don't think this is a major issue since I doubt there are any OBSD machines out there which would have all the neccessary conditions for this to be a problem. But it makes me uncomfortable that I can't prevent this information leaking from happening even if I wanted to. I would change ifconfig(8) so that you can interactively enter the key similarily how you can do that with passwd(1). What the diff does: If the key is not supplied on command line, use readpassphrase(3) to read it from tty/stdin. Echo is turned on because some keys can be very long and highly error-prone (wpa hexkey). After we're done, bzero the key as it is recommended in readpassphrase(3) manpage. Tested only wpakey, only on i386. Further ideas: * Maybe depracate and disable the ability to pass the key on the command line at all? * The resulting awkwardness of 'nwkey persist' (i.e. you can type # ifconfig iwn0 nwkey enter the key: it asks you for a key but you can enter 'persist' and it'll be the same as typing # ifconfig iwn nwkey persist ) the awkwardness of this all is probably a hint that in case this diff or some form of it goes in, the 'persist' should somehow be reworked, maybe into it's own separate subcommand, e.g.: # ifconfig iwn0 nwkeypersist enter the key: Also, what other programs are there which allow to set some kind of a key from command line? They should be fixed too. Index: ifconfig.8 === RCS file: /OpenBSD/src/sbin/ifconfig/ifconfig.8,v retrieving revision 1.219 diff -u -p -r1.219 ifconfig.8 --- ifconfig.8 9 Jul 2011 08:44:54 - 1.219 +++ ifconfig.8 5 Sep 2011 20:58:04 - @@ -726,7 +726,7 @@ Start the bridge forwarding packets. .Op Cm carpnodes Ar vhid:advskew,vhid:advskew,... .Op Cm carpdev Ar iface .Op Oo Fl Oc Ns Cm carppeer Ar peer_address -.Op Cm pass Ar passphrase +.Op Cm pass Op Ar passphrase .Op Cm state Ar state .Op Cm vhid Ar host-id .Ek @@ -780,9 +780,11 @@ with IPv4 multicast traffic. .It Fl carppeer Send the advertisements to the default carp multicast group. -.It Cm pass Ar passphrase +.It Cm pass Op Ar passphrase Set the authentication key to .Ar passphrase . +If the passphrase is not supplied on the command line, user will be +prompted to enter it on the standard input. There is no passphrase by default. .It Cm state Ar state Explicitly force the interface to enter this state. @@ -820,7 +822,7 @@ will begin advertising as master. .Op Oo Fl Oc Ns Cm chan Op Ar n .Op Oo Fl Oc Ns Cm nwflag Ar flag .Op Oo Fl Oc Ns Cm nwid Ar id -.Op Oo Fl Oc Ns Cm nwkey Ar key +.Op Oo Fl Oc Ns Cm nwkey Op Ar key .Op Oo Fl Oc Ns Cm powersave Op Ar duration .Op Cm scan .Op Oo Fl Oc Ns Cm txpower Ar dBm @@ -828,7 +830,7 @@ will begin advertising as master. .Op Cm wpaakms Ar akm,akm,... .Op Cm wpaciphers Ar cipher,cipher,... .Op Cm wpagroupcipher Ar cipher -.Op Oo Fl Oc Ns Cm wpakey Ar passphrase | hexkey +.Op Oo Fl Oc Ns Cm wpakey Op Ar passphrase | hexkey .Op Cm wpaprotos Ar proto,proto,... .Ek .nr nS 0 @@ -893,9 +895,11 @@ Note that network ID is synonymous with .It Fl nwid Set the network ID to the empty string to allow the interface to connect to any available access point. -.It Cm nwkey Ar key +.It Cm nwkey Op Ar key Enable WEP encryption using the specified .Ar key . +If the key is not supplied on the command line, user will be +prompted to enter it on the standard input. The .Ar key can either be a string, a series of hexadecimal digits (preceded by @@ -922,12 +926,17 @@ The length of each key must be either 40 Disable WEP encryption. .It Cm nwkey Cm persist Enable WEP encryption using the persistent key stored in the network card. -.It Cm nwkey Cm persist : Ns Ar key +.It Cm nwkey Op Cm persist : Ns Ar key Write .Ar key to the persistent memory of the network card, and enable WEP encryption using that .Ar key . +If the key is not supplied on the command line, user will be +prompted to enter it on the standard input (the whole expression +must be entered, e.g. +.Dq Cm persist : Ns Ar key +). .It Cm powersave Op Ar duration Enable 802.11 power saving mode. Optionally set the receiver sleep duration (in milliseconds). @@ -1016,8 +1025,10 @@ The .Cm wpagroupcipher option is available in Host AP mode only. A station will always use the group cipher of the BSS. -.It Cm wpakey Ar
Re: mixerctl(1) diff: sort output
On Mon, 9 May 2011 14:55:36 +0200 Alexandre Ratchov a...@caoua.org wrote: On Mon, May 09, 2011 at 02:56:28PM +0300, Sviatoslav Chagaev wrote: On Mon, May 9, 2011 at 4:48 AM, Jacob Meuser jake...@sdf.lonestar.org wrote: On Mon, May 09, 2011 at 01:32:49AM +0300, Sviatoslav Chagaev wrote: * sorted output looks cleaner, prettier; * it's easier to find the variable you're looking for in a sorted output; * hierarchical variable names yet unordered? doesn't make sense; * this way mixerctl's behaviour will be closer to other *ctl programs which output variables in an ordered fashion (audioctl, sysctl, wsconsctl). these are all matters of opinion, except for hierarchical variable names which is not technically the case here. Okay, but what about making mixerctl more similar to other *ctl? sysctl is a tree, while the mixer is not a tree. It's not either a linear bunch of strings. You are talking about how it's implemented. For all I care -- it can have neural networks inside of it. Each next layer of software provides a higher level abstraction. Device specific audio driver - device independent audio driver - mixerctl/audioctl. I always thought that the idea behind the *ctl programs is to provide a way to configure totally different things in a similar manner. Therefore *ctl programs should behave as similarily as possible. Sorting it doesn't make much sense imho. Furthermore, sorting mixctl as strings is easy with sort(1) so it's not absolutely necessary; mixerctl is the only *ctl program for which I use | sort all the time. while it would kill the widget order exposed by the driver. Both you and Jacob Meuser mentioned this, but what is this information useful for? I already can figure out which widgets are related just by looking at the names of the variables. -- Alexandre Excerpt from mixerctl(1) manpage: ... EXAMPLES Show possible values for all mixer variables, and their current settings: $ mixerctl -av inputs.mic=0,0 volume inputs.mic.mute=off [ off on ] inputs.cd=220,220 volume inputs.cd.mute=off [ off on ] inputs.dac=220,220 volume inputs.dac.mute=off [ off on ] record.record=220,220 volume record.record.source=mic [ mic cd dac ] monitor.monitor=0 volume ... Maybe the original author of mixerctl didn't think of adding sorting because on his computer the output looked more or less ordered.
Re: mixerctl(1) diff: sort output
On Mon, 9 May 2011 12:44:54 + Jacob Meuser jake...@sdf.lonestar.org wrote: On Mon, May 09, 2011 at 02:56:28PM +0300, Sviatoslav Chagaev wrote: On Mon, May 9, 2011 at 4:48 AM, Jacob Meuser jake...@sdf.lonestar.org wrote: On Mon, May 09, 2011 at 01:32:49AM +0300, Sviatoslav Chagaev wrote: * sorted output looks cleaner, prettier; * it's easier to find the variable you're looking for in a sorted output; * hierarchical variable names yet unordered? doesn't make sense; * this way mixerctl's behaviour will be closer to other *ctl programs which output variables in an ordered fashion (audioctl, sysctl, wsconsctl). these are all matters of opinion, except for hierarchical variable names which is not technically the case here. Okay, but what about making mixerctl more similar to other *ctl? *sigh* $ wsconsctl (blah) Permission denied $ usbhidctl usage: (blah) $ ikectl missing argument: $ gpioctl usage: (blah) or how about, what other *ctl program is almost entirely hardware dependent? mixerctl uses audio(4). audio manpage: audio, mixer - device-independent audio driver layer Before: note how the controls are grouped (mostly) by widget. please read azalia(4). I did notice that. Unfortunately, I can't access my amd64 machine right now. It has like 2 to 3 times the amount of variables shown here and I think I saw some vars there, for which I couldn't figure out by which criteria were they ordered. If mixerctl's intention is that the most important thing is the widget, then the widget's name should've been placed in front. I tried this just now, putting widget in front, then the mixer class -- it looks horrible, completely unscannable. Maybe the mixer class is the most important thing after all, since this is the most generic thing you can group various widgets by. ok then, why do some devices have 'outputs.dac' yet others have 'inputs.dac'? what is the difference to the user? which is more correct? why? I have absolutely no idea. I'm not an audio equipment manufacturer. I don't understand how are these questions even relevant. this has been the case since long before azalia(4). if you cannot explain this, then you just don't understand. s@d630:0:/usr/src/usr.bin/mixerctl$ mixerctl outputs.hp_source=dac-0:1 outputs.hp_dir=output outputs.hp_boost=off outputs.line-in_source=dac-2:3 outputs.line-in_dir=input outputs.mic_dir=input-vr80 outputs.spkr_source=dac-2:3 outputs.spkr_dir=none outputs.spkr_boost=off inputs.dac-2:3_mute=off inputs.dac-2:3=152,152 inputs.dac-0:1_mute=off inputs.dac-0:1=152,152 inputs.sel_source=mic outputs.sel=126,126 inputs.sel2_source=line-in outputs.sel2=126,126 inputs.sel3_source=sel inputs.sel3_sel=119,119 inputs.sel4_source=sel2 inputs.sel4_sel2=119,119 record.adc-0:1_source=sel3 record.adc-0:1_mute=off record.adc-2:3_source=sel4 record.adc-2:3_mute=off inputs.beep=85 and at the end are the pseudo controls. the ones most people are most interested in. so even if the rest of the controls scroll by when you do a simple mixerctl, you see these controls. Just by looking at these variables, I cannot distinguish which ones are pseudo and which aren't. This is an implementation detail, I think the user of an interface shouldn't have to care about implementation details. I cannot provide any evidence that most people are or are not interested in those pseudo vars, but I thought most of the time people are interested in something like play an mp3 file, watch a video, simple stuff like that. In this case one would probably be most interested in outputs, volume controls... as in, 'outputs.master' ... the one that's tied to the keyboard keys on laptops. this is by far the most important, most used mixer control. Suppose I have bought a new computer, can I predict where exactly these controls will pop up in the output? It's possible to adjust sorting and output these vars last, by modifying the cmp function. that is ridiculous. And I can argue that it is still easier to find what you're looking for when the output is sorted, especially considering that the output of mixerctl can vary widely between different computers. please do give an example of how sorting them makes finding what you're looking for easier. please. and it better be easier than piping through sort/grep. I'll repeat that you cannot rely on 'inputs' or 'outputs' having true meaning. sorry, but you can't. trust me on that one. Binary search. I might not remember the exact name of the variable. Why should I be suffering if someone has broken hardware? From all the computers I owned -- there wasn't a single time when vars were labeled incorrectly. Even if I have broken hardware, I will know this the first time I use it. No need to tell me that over
Re: aucat(1) mixing: saturating-addition instead of add-and-divide-by-n_inputs
On Sat, 14 May 2011 17:55:06 +0200
Alexandre Ratchov a...@caoua.org wrote:
On Sat, May 14, 2011 at 06:26:57PM +0300, Sviatoslav Chagaev wrote:
Then the only thing that remains -- is to add clipping in mix_badd().
Yes, if the other diff goes in, handling clipping makes sense.
This will give aucat all the bits and pieces to meet the requirements
of all kinds of users.
(Tested on i386 and amd64 with 16 and 24 bits ADATA)
Index: aproc.c
===
RCS file: /cvs/src/usr.bin/aucat/aproc.c,v
retrieving revision 1.64
diff -u -p -r1.64 aproc.c
--- aproc.c 28 Apr 2011 07:20:03 - 1.64
+++ aproc.c 14 May 2011 14:42:58 -
@@ -617,6 +617,11 @@ mix_badd(struct abuf *ibuf, struct abuf
unsigned i, j, cc, istart, inext, onext, ostart;
unsigned scount, icount, ocount;
int vol;
+#if ADATA_BITS = 16
+ register int data;
+#else
+ register long long data;
+#endif
it's ok this to be an int in both cases, since ints are 32-bit
an samples are at most 24-bit.
#ifdef DEBUG
if (debug_level = 4) {
@@ -673,7 +678,13 @@ mix_badd(struct abuf *ibuf, struct abuf
idata += istart;
for (i = scount; i 0; i--) {
for (j = cc; j 0; j--) {
- *odata += ADATA_MUL(*idata, vol);
+ data = *odata;
+ data += ADATA_MUL(*idata, vol);
+ if (data -ADATA_UNIT)
+ data = -ADATA_UNIT;
+ else if (data (ADATA_UNIT-2))
+ data = (ADATA_UNIT-2);
^^
ADATA_UNIT - 1
samles are in the -ADATA_UNIT .. (ADATA_UNIT - 1) range
Sorry =(
+ *odata = (adata_t) data;
idata++;
odata++;
}
-- Alexandre
Re: aucat(1) mixing: saturating-addition instead of add-and-divide-by-n_inputs
On Wed, 11 May 2011 03:35:56 +
Jacob Meuser jake...@sdf.lonestar.org wrote:
clipping is better than normalizing? really?
Clipping might describe something like value0xff, so no, not
clipping, saturating addition.
Try it and see for yourself.
what about the case where aucat is used for offline mixing?
What about it?
like the mixerctl change, you are taking away things that exist
for good reason, because it makes *your* situation better in *your*
opinion, when you can (mostly) have what you want with the current
code (if you just try a little).
I'm not taking anything away, I'm setting things right.
Like I already said, the -v option stays fully functional.
Everything can be boiled down to opinion. Please don't answer
in the style you're wrong because I said so.
I've already given enough insight and evidence as to per why the
way it's done currently is wrong.
Explain why it's not important to adhere to the least surprise
principle.
Explain why is it better to force the users to choose between
two evils when they could be offered one good.
Explain why aucat should not model real world sound physics.
On Wed, May 11, 2011 at 02:50:36AM +0300, Sviatoslav Chagaev wrote:
I'm sitting at work, listening to music, debugging a web-application
with JavaScript alert()s. Each time an alert window pops up, the
browser plays a sound. For a brief moment, the volume drops twicefold
then goes back to normal. This is annoying and doesn't make sense.
In real life, if you are surrounded by multiple sound sources, their
sound volumes will not be divided by the total amount of sound sources.
Their sounds will add up until they blur and you can't distinguish
anything anymore. Other operating systems, such as Macrohard Doors, do
mixing by modeling this real world behaviour.
In this sense, aucat violates the principle of least surprise.
I'm used to how sound interacts in real world and then aucat steps in
and introduces it's own laws of physics.
To remedy this, aucat has an option -v, which lets you pre-divide the
volume of inputs. This results in loss of dynamic range (quiet sounds
might disappear and the maximum volume that you can set decreases). And
also, if during usage the count of inputs raises above of what I
predicted, the volume starts to jump up and down again.
Experimentally, I've found that if you do a saturating addition between
inputs, it sounds very much how it might have sounded in real world and
how Macrohard Doors, among others, sounds like when playing
multiple sounds.
So, why is what I'm proposing better than what currently exists:
* Resembles how sound behaves in real world more closely;
* Doesn't violate the principle of least surprise;
* No more annoying volume jumps up and down;
* No need to use the -v option anymore / less stuff to remember / it
just works;
* No more choosing between being annoyed by volume jumps or loosing
dynamic range.
(This doesn't affect the -v option, it remains fully functional.)
Tested on i386 and amd64 with 16 bits and 24 bits.
Index: abuf.h
===
RCS file: /OpenBSD/src/usr.bin/aucat/abuf.h,v
retrieving revision 1.23
diff -u -r1.23 abuf.h
--- abuf.h 21 Oct 2010 18:57:42 - 1.23
+++ abuf.h 10 May 2011 22:58:18 -
@@ -46,7 +46,6 @@
union {
struct {
int weight; /* dynamic range */
- int maxweight; /* max dynamic range allowed */
unsigned vol; /* volume within the dynamic range */
unsigned done; /* frames ready */
unsigned xrun; /* underrun policy */
Index: aparams.h
===
RCS file: /OpenBSD/src/usr.bin/aucat/aparams.h,v
retrieving revision 1.11
diff -u -r1.11 aparams.h
--- aparams.h 5 Nov 2010 16:42:17 - 1.11
+++ aparams.h 10 May 2011 22:58:18 -
@@ -19,6 +19,8 @@
#include sys/param.h
+#include limits.h
+
#define NCHAN_MAX 16 /* max channel in a stream */
#define RATE_MIN 4000/* min sample rate */
#define RATE_MAX 192000 /* max sample rate */
@@ -64,6 +66,9 @@
typedef short adata_t;
+#define ADATA_MIN SHRT_MIN
+#define ADATA_MAX SHRT_MAX
+
#define ADATA_MUL(x,y) (((int)(x) * (int)(y)) (ADATA_BITS -
1))
#define ADATA_MULDIV(x,y,z)((int)(x) * (int)(y) / (int)(z))
@@ -71,6 +76,9 @@
typedef int adata_t;
+#define ADATA_MIN (-0xff / 2)
+#define ADATA_MAX (0xff / 2)
+
#if defined(__i386__) defined(__GNUC__)
static inline int
@@ -119,6 +127,28 @@
#else
#error only 16-bit and 24-bit precisions are supported
#endif
+
+/* saturating addition
Re: aucat(1) mixing: saturating-addition instead of add-and-divide-by-n_inputs
On Wed, 11 May 2011 13:07:12 +0200
Alexandre Ratchov a...@caoua.org wrote:
On Wed, May 11, 2011 at 02:50:36AM +0300, Sviatoslav Chagaev wrote:
below are few comments about the diff itself
Index: aparams.h
===
RCS file: /OpenBSD/src/usr.bin/aucat/aparams.h,v
retrieving revision 1.11
diff -u -r1.11 aparams.h
--- aparams.h 5 Nov 2010 16:42:17 - 1.11
+++ aparams.h 10 May 2011 22:58:18 -
@@ -19,6 +19,8 @@
#include sys/param.h
+#include limits.h
+
#define NCHAN_MAX 16 /* max channel in a stream */
#define RATE_MIN 4000/* min sample rate */
#define RATE_MAX 192000 /* max sample rate */
@@ -64,6 +66,9 @@
typedef short adata_t;
+#define ADATA_MIN SHRT_MIN
+#define ADATA_MAX SHRT_MAX
+
these don't hurt but there's a ADATA_UNIT macro that could do the job,
I'd prefer having only one macro.
@@ -119,6 +127,28 @@
#else
#error only 16-bit and 24-bit precisions are supported
#endif
+
+/* saturating addition */
+static inline adata_t
+adata_sadd(register adata_t x, register adata_t y)
+{
+#if ADATA_BITS = 16
+ register int sum;
+#else
+ register long long sum;
+#endif
+
+ sum = x;
+ sum += y;
+
+ if (sum ADATA_MIN)
+ sum = ADATA_MIN;
+ else if (sum ADATA_MAX)
+ sum = ADATA_MAX;
+
+ return (adata_t) sum;
+}
+#define ADATA_SADD(x,y)adata_sadd(x,y)
you could inline this in mix_badd(), since it's the only place where
clipping can occur
Index: aproc.c
===
RCS file: /OpenBSD/src/usr.bin/aucat/aproc.c,v
retrieving revision 1.64
diff -u -r1.64 aproc.c
--- aproc.c 28 Apr 2011 07:20:03 - 1.64
+++ aproc.c 10 May 2011 22:58:19 -
@@ -617,6 +617,7 @@
unsigned i, j, cc, istart, inext, onext, ostart;
unsigned scount, icount, ocount;
int vol;
+ adata_t sample;
this should be 'int', adata_t is used for storage only.
@@ -914,8 +916,6 @@
struct abuf *i, *obuf = LIST_FIRST(p-outs);
unsigned odone;
- mix_setmaster(p);
-
this shouldn't be removed because this is the only way to avoid
clipping and keeping the full dynamic range. Perhaps make it a
device-specific option (see how -a option is implemented).
Index: dev.c
===
RCS file: /OpenBSD/src/usr.bin/aucat/dev.c,v
retrieving revision 1.64
diff -u -r1.64 dev.c
--- dev.c 21 Oct 2010 18:57:42 - 1.64
+++ dev.c 10 May 2011 22:58:19 -
@@ -998,8 +998,7 @@
}
aproc_setin(d-mix, ibuf);
ibuf-r.mix.xrun = xrun;
- ibuf-r.mix.maxweight = vol;
- mix_setmaster(d-mix);
+ ibuf-r.mix.weight = vol;
maxweight should stay there, this is the maximum volume of the
sub-device socket. It's used to cap volumes of clients of a particular
sub-device.
Thanks, I'll keep these in mind when making the next diff.
[...]
I don't have a clear opinion. On the one hand, clipping is not
acceptable for me. On the other hand it is statistically rare and a
lot of people here would be more annoyed by the volume step, than by
occasional clipping.
You could try fixing above issues, and let people use the diff for
long enough and see if quality is acceptable.
Perhaps disable the mix_badd() change in the beginning, since it tends
to make clipping less audible; this way we can see how often clipping
occurs.
You've given me enough insight to come up with another, hopefully,
better idea. When the diff is ready I'll start a new thread.
Thanks.
-- Alexandre
Re: aucat(1) mixing: saturating-addition instead of add-and-divide-by-n_inputs
On Wed, 11 May 2011 13:25:47 +0200 Alexandre Ratchov a...@caoua.org wrote: On Wed, May 11, 2011 at 09:45:05AM +0300, Sviatoslav Chagaev wrote: On Wed, 11 May 2011 03:35:56 + Jacob Meuser jake...@sdf.lonestar.org wrote: clipping is better than normalizing? really? Clipping might describe something like value0xff, so no, not clipping, saturating addition. Try it and see for yourself. truncating higher bits or clipping alter the stream non-linearly and imo both are evil. But I think the lowering of dynamic range also degrades the quality. You had 100 different values and then you suddenly have, say 20, some information has been lost... what about the case where aucat is used for offline mixing? What about it? I'd like aucat -n -o result.wav -i file1.wav -i file2.wav to not saturate. As far as I've read undeadly.org, you're a musician. I do understand that you require very precise control of audio and various processing operations. But I think most users probably aren't that sophisticated and are more interested in the sound system just working, so that mp3s play, videos can be watched and aucat doesn't surprise them by having it's own will and changing the volume when it feels like it. like the mixerctl change, you are taking away things that exist for good reason, because it makes *your* situation better in *your* opinion, when you can (mostly) have what you want with the current code (if you just try a little). I'm not taking anything away, I'm setting things right. Like I already said, the -v option stays fully functional. Everything can be boiled down to opinion. Please don't answer in the style you're wrong because I said so. It's more complicated that i'm right so you're wrong. Mixing (as other processing in aucat) is best effort. It's a compromise between quality loss by distortion and by dynamic range reduction. I've already given enough insight and evidence as to per why the way it's done currently is wrong. Come on, both approches are physcally wrong, it's a matter of taste, and the way you claim it's wrong tends to be irritating. Espectially since this is 3+ years old code, and you guess this was discussed plenty of times. Yes, you are right. We can model what happens with sound in real world only to some degree. Explain why it's not important to adhere to the least surprise principle. least surprise priciple for me is: streams do not suffer non-linear distortion when played through aucat. I see. For me, a regular Joe User, the least surprising thing would be for aucat to do mixing in a similar manner to what I have previously experienced, i.e. similar to how it happens in real world and in other OS. Explain why is it better to force the users to choose between two evils when they could be offered one good. Because diffent users may have different needs. That is true, but I believe it is possible to do things in such a way, so that ordinary users who are not interested in super-advanced functionality can be freed from the burdens. Explain why aucat should not model real world sound physics. because DACs have limited dynamic range; if you use -v 100, your closer to sound physics than with clipping. We are talking about a system which directly interfaces to human sensory inputs. I think we can't rely only on logic in this case, subjective feelings have even higher priority. Consider MP3 for example -- it doesn't even try to be as precise as possible, rather, it makes it so that it would seem to humans that it sounds ok, but in reality the sound gets distorted. [...] And note that two approaches are not exclusive. If you don't like the way dynamic range is shared, roll a nice diff to disable this feature. If people like it, and it hurts nobody, they will take it. I agree, I think a hybrid approach could be used. -- Alexandre
Re: aucat(1) mixing: saturating-addition instead of add-and-divide-by-n_inputs
On Wed, 11 May 2011 19:58:56 + Jacob Meuser jake...@sdf.org wrote: On Wed, May 11, 2011 at 09:45:05AM +0300, Sviatoslav Chagaev wrote: On Wed, 11 May 2011 03:35:56 + Jacob Meuser jake...@sdf.lonestar.org wrote: clipping is better than normalizing? really? Clipping might describe something like value0xff, so no, not clipping, saturating addition. + if (sum ADATA_MIN) + sum = ADATA_MIN; + else if (sum ADATA_MAX) + sum = ADATA_MAX; http://en.wikipedia.org/wiki/Clipping_(audio) Alright. Try it and see for yourself. it is like jackd, which I find annoying. I agree, changing volume of an active stream is annoying, but there is a reason for it. what about the case where aucat is used for offline mixing? What about it? it's a very different use case than the one you're trying to fix. I'm asking you how your fix is going to affect that use case. With the (already obsolete, so it doesn't matter anymore) diff that I posted, people who require this normalization would have to use the -v option. like the mixerctl change, you are taking away things that exist for good reason, because it makes *your* situation better in *your* opinion, when you can (mostly) have what you want with the current code (if you just try a little). I'm not taking anything away, you most certainly are. whether or not you believe the code to be correct/useful is irrelevant, you are removing something. Whether it is a good thing or a bad thing is another question. I'm setting things right. lemme offer a suggestion. the next time you run into something that doesn't make any sense to you, check if someone else has already questioned it and if any reason has already been given. or at least ask why instead of asserting that it is wrong. that will get you more sympathy, from me anyway. My impression is that the opposite is true on tech@: if you don't have a diff -- it's just empty, useless talk and you shouldn't post if you don't have a diff. Besides, looking from an ordinary Joe User viewpoint, I don't think there is anything that could convince me that aucat is presently appropriatly handling the task of being a system sound server. (Alexandre already gave me enough information about why things are the way they are; I don't see any problem in making everyone happy, the Joe Users who want the sound system to just work and advanced audio-philes who require advanced features and precision control) -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
aucat(1) mixing: saturating-addition instead of add-and-divide-by-n_inputs
I'm sitting at work, listening to music, debugging a web-application
with JavaScript alert()s. Each time an alert window pops up, the
browser plays a sound. For a brief moment, the volume drops twicefold
then goes back to normal. This is annoying and doesn't make sense.
In real life, if you are surrounded by multiple sound sources, their
sound volumes will not be divided by the total amount of sound sources.
Their sounds will add up until they blur and you can't distinguish
anything anymore. Other operating systems, such as Macrohard Doors, do
mixing by modeling this real world behaviour.
In this sense, aucat violates the principle of least surprise.
I'm used to how sound interacts in real world and then aucat steps in
and introduces it's own laws of physics.
To remedy this, aucat has an option -v, which lets you pre-divide the
volume of inputs. This results in loss of dynamic range (quiet sounds
might disappear and the maximum volume that you can set decreases). And
also, if during usage the count of inputs raises above of what I
predicted, the volume starts to jump up and down again.
Experimentally, I've found that if you do a saturating addition between
inputs, it sounds very much how it might have sounded in real world and
how Macrohard Doors, among others, sounds like when playing
multiple sounds.
So, why is what I'm proposing better than what currently exists:
* Resembles how sound behaves in real world more closely;
* Doesn't violate the principle of least surprise;
* No more annoying volume jumps up and down;
* No need to use the -v option anymore / less stuff to remember / it
just works;
* No more choosing between being annoyed by volume jumps or loosing
dynamic range.
(This doesn't affect the -v option, it remains fully functional.)
Tested on i386 and amd64 with 16 bits and 24 bits.
Index: abuf.h
===
RCS file: /OpenBSD/src/usr.bin/aucat/abuf.h,v
retrieving revision 1.23
diff -u -r1.23 abuf.h
--- abuf.h 21 Oct 2010 18:57:42 - 1.23
+++ abuf.h 10 May 2011 22:58:18 -
@@ -46,7 +46,6 @@
union {
struct {
int weight; /* dynamic range */
- int maxweight; /* max dynamic range allowed */
unsigned vol; /* volume within the dynamic range */
unsigned done; /* frames ready */
unsigned xrun; /* underrun policy */
Index: aparams.h
===
RCS file: /OpenBSD/src/usr.bin/aucat/aparams.h,v
retrieving revision 1.11
diff -u -r1.11 aparams.h
--- aparams.h 5 Nov 2010 16:42:17 - 1.11
+++ aparams.h 10 May 2011 22:58:18 -
@@ -19,6 +19,8 @@
#include sys/param.h
+#include limits.h
+
#define NCHAN_MAX 16 /* max channel in a stream */
#define RATE_MIN 4000/* min sample rate */
#define RATE_MAX 192000 /* max sample rate */
@@ -64,6 +66,9 @@
typedef short adata_t;
+#define ADATA_MIN SHRT_MIN
+#define ADATA_MAX SHRT_MAX
+
#define ADATA_MUL(x,y) (((int)(x) * (int)(y)) (ADATA_BITS - 1))
#define ADATA_MULDIV(x,y,z)((int)(x) * (int)(y) / (int)(z))
@@ -71,6 +76,9 @@
typedef int adata_t;
+#define ADATA_MIN (-0xff / 2)
+#define ADATA_MAX (0xff / 2)
+
#if defined(__i386__) defined(__GNUC__)
static inline int
@@ -119,6 +127,28 @@
#else
#error only 16-bit and 24-bit precisions are supported
#endif
+
+/* saturating addition */
+static inline adata_t
+adata_sadd(register adata_t x, register adata_t y)
+{
+#if ADATA_BITS = 16
+ register int sum;
+#else
+ register long long sum;
+#endif
+
+ sum = x;
+ sum += y;
+
+ if (sum ADATA_MIN)
+ sum = ADATA_MIN;
+ else if (sum ADATA_MAX)
+ sum = ADATA_MAX;
+
+ return (adata_t) sum;
+}
+#define ADATA_SADD(x,y)adata_sadd(x,y)
#define MIDI_MAXCTL127
#define MIDI_TO_ADATA(m) (aparams_ctltovol[m] (ADATA_BITS - 16))
Index: aproc.c
===
RCS file: /OpenBSD/src/usr.bin/aucat/aproc.c,v
retrieving revision 1.64
diff -u -r1.64 aproc.c
--- aproc.c 28 Apr 2011 07:20:03 - 1.64
+++ aproc.c 10 May 2011 22:58:19 -
@@ -617,6 +617,7 @@
unsigned i, j, cc, istart, inext, onext, ostart;
unsigned scount, icount, ocount;
int vol;
+ adata_t sample;
#ifdef DEBUG
if (debug_level = 4) {
@@ -673,7 +674,8 @@
idata += istart;
for (i = scount; i 0; i--) {
for (j = cc; j 0; j--) {
- *odata += ADATA_MUL(*idata, vol);
+ sample = ADATA_MUL(*idata, vol);
+ *odata = ADATA_SADD(*odata, sample);
idata++;
Re: mixerctl(1) diff: sort output
On Mon, May 9, 2011 at 4:48 AM, Jacob Meuser jake...@sdf.lonestar.org wrote: On Mon, May 09, 2011 at 01:32:49AM +0300, Sviatoslav Chagaev wrote: * sorted output looks cleaner, prettier; * it's easier to find the variable you're looking for in a sorted output; * hierarchical variable names yet unordered? doesn't make sense; * this way mixerctl's behaviour will be closer to other *ctl programs which output variables in an ordered fashion (audioctl, sysctl, wsconsctl). these are all matters of opinion, except for hierarchical variable names which is not technically the case here. Okay, but what about making mixerctl more similar to other *ctl? Before: note how the controls are grouped (mostly) by widget. please read azalia(4). I did notice that. Unfortunately, I can't access my amd64 machine right now. It has like 2 to 3 times the amount of variables shown here and I think I saw some vars there, for which I couldn't figure out by which criteria were they ordered. If mixerctl's intention is that the most important thing is the widget, then the widget's name should've been placed in front. I tried this just now, putting widget in front, then the mixer class -- it looks horrible, completely unscannable. Maybe the mixer class is the most important thing after all, since this is the most generic thing you can group various widgets by. s@d630:0:/usr/src/usr.bin/mixerctl$ mixerctl outputs.hp_source=dac-0:1 outputs.hp_dir=output outputs.hp_boost=off outputs.line-in_source=dac-2:3 outputs.line-in_dir=input outputs.mic_dir=input-vr80 outputs.spkr_source=dac-2:3 outputs.spkr_dir=none outputs.spkr_boost=off inputs.dac-2:3_mute=off inputs.dac-2:3=152,152 inputs.dac-0:1_mute=off inputs.dac-0:1=152,152 inputs.sel_source=mic outputs.sel=126,126 inputs.sel2_source=line-in outputs.sel2=126,126 inputs.sel3_source=sel inputs.sel3_sel=119,119 inputs.sel4_source=sel2 inputs.sel4_sel2=119,119 record.adc-0:1_source=sel3 record.adc-0:1_mute=off record.adc-2:3_source=sel4 record.adc-2:3_mute=off inputs.beep=85 and at the end are the pseudo controls. the ones most people are most interested in. so even if the rest of the controls scroll by when you do a simple mixerctl, you see these controls. Just by looking at these variables, I cannot distinguish which ones are pseudo and which aren't. This is an implementation detail, I think the user of an interface shouldn't have to care about implementation details. I cannot provide any evidence that most people are or are not interested in those pseudo vars, but I thought most of the time people are interested in something like play an mp3 file, watch a video, simple stuff like that. In this case one would probably be most interested in outputs, volume controls... It's possible to adjust sorting and output these vars last, by modifying the cmp function. And I can argue that it is still easier to find what you're looking for when the output is sorted, especially considering that the output of mixerctl can vary widely between different computers. outputs.hp_sense=plugged outputs.line-in_sense=unplugged outputs.spkr_muters=hp,line-in outputs.master=153,153 outputs.master.mute=off outputs.master.slaves=dac-2:3,dac-0:1 record.volume=0,0 record.volume.mute=off record.volume.slaves=adc-0:1,adc-2:3 After: s@d630:0:/usr/src/usr.bin/mixerctl$ ./mixerctl inputs.beep=85 inputs.dac-0:1=152,152 inputs.dac-0:1_mute=off inputs.dac-2:3=152,152 inputs.dac-2:3_mute=off inputs.sel2_source=line-in inputs.sel3_sel=119,119 inputs.sel3_source=sel inputs.sel4_sel2=119,119 inputs.sel4_source=sel2 inputs.sel_source=mic outputs.hp_boost=off outputs.hp_dir=output outputs.hp_sense=plugged outputs.hp_source=dac-0:1 outputs.line-in_dir=input outputs.line-in_sense=unplugged outputs.line-in_source=dac-2:3 outputs.master=153,153 outputs.master.mute=off outputs.master.slaves=dac-2:3,dac-0:1 outputs.mic_dir=input-vr80 outputs.sel=126,126 outputs.sel2=126,126 outputs.spkr_boost=off outputs.spkr_dir=none outputs.spkr_muters=hp,line-in outputs.spkr_source=dac-2:3 record.adc-0:1_mute=off record.adc-0:1_source=sel3 record.adc-2:3_mute=off record.adc-2:3_source=sel4 record.volume=0,0 record.volume.mute=off record.volume.slaves=adc-0:1,adc-2:3 I do not find this more useful. prettier, perhaps, but not more useful. in particular, this (further) breaks the widget-wise grouping on some devices. please read azalia(4), inputs and outputs is really just a hint, and making it more precise is much more difficult than adding sorting to mixerctl ... Well it doesn't add any new functionality or anything, sure. I'm just trying to improve my user experience. For me, this would be useful because I wouldn't have to append | sort to mixerctl every time I use it, and because I wouldn't have to remember that it works slightly differently than other *ctl programs. It would also be more aesthetically pleasing, making my computer just
Re: mixerctl(1) diff: sort output
On Mon, May 9, 2011 at 3:27 AM, Abel Abraham Camarillo Ojeda acam...@verlet.org wrote: On Sun, May 8, 2011 at 5:32 PM, Sviatoslav Chagaev sviatoslav.chag...@gmail.com wrote: ... Am I missing something? $ sysctl | sort /tmp/sysctl_sorted $ sysctl | cmp -s /tmp/sysctl_sorted /dev/stdin || echo different; different $ At the very least, other *ctl don't intermix toplevel nodes, like kern... kern... hw... kern...
cwm diff: some fixes and improvements
[calmwm.h, conf.c, mousefunc.c, parse.y]
When a window is being moved with the mouse, if the window comes within
SNAPDIST pixels of the screen's edge -- snap the window to the screen's
edge.
[kbfunc.c]
Suppose moveamount=1, then bigmoveamount=10. The window is 3 pixels
away from the screen's edge. If the window is moved by bigmoveamount
toward the screen edge, then it will align itself perfectly along the
screen's edge, i.e. travel only 3 pixels, instead of 10. Subsequent
moves don't have any special behaviour. Works both ways: when moving a
window from beyond the screen to within and vice versa.
[menu.c]
Bugfix: the menu code ignores the fact that it might be on a multi-head
configuration, where screens are configured to be atop of each other,
e.g. xrandr --output LVDS --primary --auto xrandr --output TMDS-1
--above LVDS --auto In this case when a menu containing a lot of
entries is opened, it will span both screens, which is quite annoying
and contradicts cwm's behaviour regarding placing new windows and
window maximization.
[menu.c]
Don't move the pointer when resizing the menu. Reasoning: I already
have my pointer right where I want it to be, thank you very much. For
example, hovering above a certain control of a program that I'm about
to launch.
[screen.c]
Fix screen_find_xinerama(). For example, pixel (0,0) belongs to the
top-left-most screen.
Index: calmwm.h
===
RCS file: /OpenBSD/xenocara/app/cwm/calmwm.h,v
retrieving revision 1.118
diff -u -r1.118 calmwm.h
--- calmwm.h22 May 2010 22:10:31 - 1.118
+++ calmwm.h16 Mar 2011 20:16:33 -
@@ -287,10 +287,12 @@
#defineCONF_STICKY_GROUPS 0x0001
int flags;
-#define CONF_BWIDTH 1
+#defineCONF_BWIDTH 1
int bwidth;
#defineCONF_MAMOUNT 1
int mamount;
+#defineCONF_SNAPDIST12
+ int snapdist;
struct gap gap;
#define CONF_COLOR_ACTIVEBORDER#CC
Index: conf.c
===
RCS file: /OpenBSD/xenocara/app/cwm/conf.c,v
retrieving revision 1.76
diff -u -r1.76 conf.c
--- conf.c 27 Jan 2010 03:04:50 - 1.76
+++ conf.c 16 Mar 2011 20:16:33 -
@@ -184,6 +184,7 @@
c-flags = 0;
c-bwidth = CONF_BWIDTH;
c-mamount = CONF_MAMOUNT;
+ c-snapdist = CONF_SNAPDIST;
TAILQ_INIT(c-ignoreq);
TAILQ_INIT(c-cmdq);
Index: kbfunc.c
===
RCS file: /OpenBSD/xenocara/app/cwm/kbfunc.c,v
retrieving revision 1.51
diff -u -r1.51 kbfunc.c
--- kbfunc.c10 Feb 2010 01:23:05 - 1.51
+++ kbfunc.c16 Mar 2011 20:16:33 -
@@ -55,8 +55,11 @@
kbfunc_moveresize(struct client_ctx *cc, union arg *arg)
{
struct screen_ctx *sc;
- int x, y, flags, amt;
+ int x, y, right, bottom, bwidth2, flags, amt;
+ int old_x, old_y, old_right, old_bottom;
+ int xmin, ymin, xmax, ymax;
u_intmx, my;
+ XineramaScreenInfo *xine;
sc = cc-sc;
mx = my = 0;
@@ -69,6 +72,20 @@
amt = amt * 10;
}
+ xine = screen_find_xinerama(sc,
+ cc-geom.x + cc-geom.width/2, cc-geom.y + cc-geom.height/2);
+ if (xine) {
+ xmin = xine-x_org;
+ ymin = xine-y_org;
+ xmax = xine-x_org + xine-width;
+ ymax = xine-y_org + xine-height;
+ } else {
+ xmin = 0;
+ ymin = 0;
+ xmax = sc-xmax;
+ ymax = sc-ymax;
+ }
+
switch (flags movemask) {
case CWM_UP:
my -= amt;
@@ -85,22 +102,47 @@
}
switch (flags typemask) {
case CWM_MOVE:
- cc-geom.y += my;
+ bwidth2 = cc-bwidth * 2;
+
+ old_y = cc-geom.y;
+ old_bottom = old_y + cc-geom.height + bwidth2;
+ old_x = cc-geom.x;
+ old_right = old_x + cc-geom.width + bwidth2;
+
+ y = cc-geom.y + my;
+ bottom = y + cc-geom.height + bwidth2;
+ x = cc-geom.x + mx;
+ right = x + cc-geom.width + bwidth2;
+
+ if (abs(ymin - old_y) abs(my) abs(ymin - y) abs(my))
+ y = ymin;
+ else if (abs(ymax - old_bottom) abs(my)
+abs(ymax - bottom) abs(my))
+ y = ymax - cc-geom.height - bwidth2;
+
+ if (abs(xmin - old_x) abs(mx) abs(xmin - x) abs(mx))
+ x = xmin;
+ else if (abs(xmax - old_right) abs(mx)
+abs(xmax
Re: cwm diff: some fixes and improvements
On Wed, 16 Mar 2011 22:31:06 +0200 Sviatoslav Chagaev 0x1...@gmail.com wrote: [calmwm.h, conf.c, mousefunc.c, parse.y] When a window is being moved with the mouse, if the window comes within SNAPDIST pixels of the screen's edge -- snap the window to the screen's edge. [kbfunc.c] Suppose moveamount=1, then bigmoveamount=10. The window is 3 pixels away from the screen's edge. If the window is moved by bigmoveamount toward the screen edge, then it will align itself perfectly along the screen's edge, i.e. travel only 3 pixels, instead of 10. Subsequent moves don't have any special behaviour. Works both ways: when moving a window from beyond the screen to within and vice versa. [menu.c] Bugfix: the menu code ignores the fact that it might be on a multi-head configuration, where screens are configured to be atop of each other, e.g. xrandr --output LVDS --primary --auto xrandr --output TMDS-1 --above LVDS --auto In this case when a menu containing a lot of entries is opened, it will span both screens, which is quite annoying and contradicts cwm's behaviour regarding placing new windows and window maximization. [menu.c] Don't move the pointer when resizing the menu. Reasoning: I already have my pointer right where I want it to be, thank you very much. For example, hovering above a certain control of a program that I'm about to launch. [screen.c] Fix screen_find_xinerama(). For example, pixel (0,0) belongs to the top-left-most screen. Forgot about the manpage. Index: cwmrc.5 === RCS file: /OpenBSD/xenocara/app/cwm/cwmrc.5,v retrieving revision 1.34 diff -u -r1.34 cwmrc.5 --- cwmrc.5 25 Sep 2010 21:48:08 - 1.34 +++ cwmrc.5 16 Mar 2011 20:41:25 - @@ -185,6 +185,12 @@ in pixels. The default is 1. .Pp +.It Ic snapdist Ic Ar pixels +When moving a window using the mouse, if the window comes within +.Ar pixels +of the screen's edge, then the window will be snapped to that edge. +The default is 12. +.Pp .It Ic sticky Ic yes Ns \| Ns Ic no Toggle sticky group mode. The default behavior for new windows is to not assign any group.
Re: ral(4) diff
On Thu, 10 Mar 2011 22:07:09 +0100 Tim van der Molen tb...@xs4all.nl wrote: I have the following ral(4): ral0 at pci0 dev 13 function 0 Ralink RT2561S rev 0x00: irq 5, address 00:1d:7d:49:28:92 ral0: MAC/BBP RT2561C, RF RT2527 After a commit from August 2010 (see http://marc.info/?l=openbsd-cvsm=128095139804862) the ral stopped working: clients could not associate with it in hostap mode and it could not detect other APs with ifconfig scan. After a hint from damien@ I came up with the following diff which brings back some of the code that was removed by the commit mentioned above. damien@ suggested I post the diff here. If you have an RT2561 or RT2661, please test it. Regards, Tim Without the patch: after boot I type `ifconfig ral0 scan`, it outputs the list of detected APs. All subsequent `ifconfig` commands have no effect, including turning on 'monitor' and 'hostap'. Also, during or shortly after the second `ifconfig ral0 scan`, a kernel message appears saying ral0: device timeout. With the patch: everything works as expected, including hostap mode. OpenBSD 4.9-current (GENERIC) #1: Sun Mar 13 01:07:58 EET 2011 r...@scenic.my.domain:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel Pentium III (GenuineIntel 686-class) 862 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PSE36,MMX,FXSR,SSE real mem = 266891264 (254MB) avail mem = 252387328 (240MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 03/11/02, BIOS32 rev. 0 @ 0xfd880, SMBIOS rev. 2.31 @ 0xefda0 (77 entries) bios0: vendor FUJITSU SIEMENS // Phoenix Technologies Ltd. version 4.06 Rev. 1.10.1215 date 03/11/2002 bios0: FUJITSU SIEMENS SCENIC xS/SCOVERY xS apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown acpi at bios0 function 0x0 not configured pcibios0 at bios0: rev 2.1 @ 0xfd880/0x780 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdf20/192 (10 entries) pcibios0: PCI Interrupt Router at 000:31:0 (Intel 82371FB ISA rev 0x00) pcibios0: PCI bus #1 is the last bus bios0: ROM list: 0xc/0xc000! 0xcc000/0x1000! 0xcd000/0x4000! cpu0 at mainbus0: (uniprocessor) pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82815 Host rev 0x04 vga1 at pci0 dev 2 function 0 Intel 82815 Video rev 0x04 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) intagp0 at vga1 agp0 at intagp0: aperture at 0xf800, size 0x400 ppb0 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0x05 pci1 at ppb0 bus 1 fxp0 at pci1 dev 8 function 0 Intel 82562 rev 0x03, i82562: irq 15, address 00:30:05:17:e5:c6 inphy0 at fxp0 phy 1: i82562EM 10/100 PHY, rev. 0 sis0 at pci1 dev 9 function 0 SiS 900 10/100BaseTX rev 0x02: irq 11, address 00:06:4f:0e:94:ed ukphy0 at sis0 phy 0: Generic IEEE 802.3u media interface, rev. 0: OUI 0x000760, model 0x ral0 at pci1 dev 11 function 0 Ralink RT2561S rev 0x00: irq 9, address 00:0e:2e:4e:77:f1 ral0: MAC/BBP RT2561C, RF RT2527 ichpcib0 at pci0 dev 31 function 0 Intel 82801BA LPC rev 0x05: 24-bit timer at 3579545Hz pciide0 at pci0 dev 31 function 1 Intel 82801BA IDE rev 0x05: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: SAMSUNG SP0802N wd0: 16-sector PIO, LBA48, 76351MB, 156368016 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 pciide0: channel 1 ignored (disabled) uhci0 at pci0 dev 31 function 2 Intel 82801BA USB rev 0x05: irq 9 ichiic0 at pci0 dev 31 function 3 Intel 82801BA SMBus rev 0x05: irq 5 iic0 at ichiic0 spdmem0 at iic0 addr 0x55: 128MB SDRAM non-parity PC133CL2 spdmem1 at iic0 addr 0x56: 128MB SDRAM non-parity PC133CL3 uhci1 at pci0 dev 31 function 4 Intel 82801BA USB rev 0x05: irq 11 auich0 at pci0 dev 31 function 5 Intel 82801BA AC97 rev 0x05: irq 5, ICH2 AC97 ac97: codec id 0x41445360 (Analog Devices AD1885) ac97: codec features headphone, Analog Devices Phat Stereo audio0 at auich0 isa0 at ichpcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 usb0 at uhci0: USB revision 1.0 uhub0 at usb0 Intel UHCI root hub rev 1.00/1.00 addr 1 usb1 at uhci1: USB revision 1.0 uhub1 at usb1 Intel UHCI root hub rev 1.00/1.00 addr 1 biomask 7ffd netmask fffd ttymask mtrr: Pentium Pro MTRR support vscsi0 at root scsibus0 at vscsi0: 256 targets softraid0 at root root on wd0a swap on wd0b dump on wd0b
fix wsmoused(8) too-high-speed issue
Tested on amd64-current, with a standard Logitech USB mouse and an
A4Tech serial mouse (detects as microsoft type), seems to work nicely.
Index: wsmoused.8
===
RCS file: /cvs/src/usr.sbin/wsmoused/wsmoused.8,v
retrieving revision 1.18
diff -u -r1.18 wsmoused.8
--- wsmoused.8 5 Jun 2009 06:50:52 - 1.18
+++ wsmoused.8 4 Sep 2010 19:22:17 -
@@ -40,6 +40,8 @@
.Fl M
.Ar N Ns = Ns Ar M
.Oc
+.Op Fl a Ar accel
+.Op Fl r Ar resist
.Op Fl p Ar device
.Op Fl t Ar type
.Sh DESCRIPTION
@@ -94,6 +96,17 @@
.Ar file .
.It Fl i
Print the type and the protocol of the mouse and exit.
+.It Fl a Ar accel
+The acceleration that should be applied when the mouse is being moved
+with high speed.
+.Ar accel
+must be a floating point value greater than or equal to 1.0 and less than or
equal to 10.0.
+If omitted, the default value of 2.0 is used.
+.It Fl r Ar resist
+Resistance to motion, the greater this value, the slower the mouse moves.
+.Ar resist
+must be a value greater than or equal to 0 and less than or equal to 80.
+If omitted, the default value of 15 is used.
.It Fl M Ar N Ns = Ns Ar M
Assign the physical button
.Ar M
Index: wsmoused.c
===
RCS file: /cvs/src/usr.sbin/wsmoused/wsmoused.c,v
retrieving revision 1.25
diff -u -r1.25 wsmoused.c
--- wsmoused.c 21 Jun 2009 16:13:18 - 1.25
+++ wsmoused.c 4 Sep 2010 19:22:17 -
@@ -74,6 +74,8 @@
#defineDEFAULT_TTY /dev/ttyCcfg
#defineDEFAULT_PIDFILE /var/run/wsmoused.pid
+#defineDEFAULT_RESISTANCE 15
+#defineDEFAULT_ACCELERATION2.0
extern char *__progname;
extern char *mouse_names[];
@@ -83,6 +85,8 @@
int nodaemon = FALSE;
int identify = FALSE;
char *pidfile = NULL;
+int resistance = -1;
+double acceleration = -1.0;
mouse_t mouse = {
.flags = 0,
@@ -303,45 +307,69 @@
ioctl(mouse.cfd, WSDISPLAYIO_WSMOUSED, event);
}
-/* workaround for cursor speed on serial mice */
-static void
-normalize_event(struct wscons_event *event)
-{
- int dx, dy;
- int two_power = 1;
-
-/* 2: normal speed, 3: slower cursor, 1: faster cursor */
-#define NORMALIZE_DIVISOR 3
-
- switch (event-type) {
- case WSCONS_EVENT_MOUSE_DELTA_X:
- dx = abs(event-value);
- while (dx 2) {
- two_power++;
- dx = dx / 2;
- }
- event-value = event-value / (NORMALIZE_DIVISOR * two_power);
- break;
- case WSCONS_EVENT_MOUSE_DELTA_Y:
- two_power = 1;
- dy = abs(event-value);
- while (dy 2) {
- two_power++;
- dy = dy / 2;
- }
- event-value = event-value / (NORMALIZE_DIVISOR * two_power);
- break;
- }
-}
-
/* send a wscons_event to the kernel */
static int
treat_event(struct wscons_event *event)
{
+ int i;
+ enum {
+ X_ACCUM,
+ Y_ACCUM,
+ N_ACCUMS
+ };
+ static int accums[N_ACCUMS];
+ /*
+* Depending on the console's font dimensions, the pixels of the
+* screen might be rectangular instead of being square. In fact, they
+* are in default configuration, because a 8x16 font is used.
+* Compensate for this fact by adding more resistance on Y axis.
+* 4/3 is a compromise value, to compensate, but in turn not to make
+* using say 8x8 font together with wsmoused too awkward.
+* TODO (?)
+* make it so that wsmoused can detect when VT is switched and
+* so it could find out what the font dimensions on that
+* particular VT are (e.g. add VT switch event to wscons, add new
+* ioctl to request font dimensions?).
+*/
+ const double resist_mults[N_ACCUMS] = {
+ 1.0,
+ 4.0/3.0
+ };
+ static double max_speed = 1.0;
+ int resist;
struct wscons_event mapped_event;
if (IS_MOTION_EVENT(event-type)) {
- ioctl(mouse.cfd, WSDISPLAYIO_WSMOUSED, event);
+ if (event-type == WSCONS_EVENT_MOUSE_DELTA_X)
+ i = X_ACCUM;
+ else if (event-type == WSCONS_EVENT_MOUSE_DELTA_Y)
+ i = Y_ACCUM;
+ else {
+ /*
+* Delta_{w,z} aka scrollwheel events don't need any
+* additional processing such as scaling and/or
+* acceleration.
+*/
+ ioctl(mouse.cfd, WSDISPLAYIO_WSMOUSED, event);
+ return 1;
+ }
+
+ if (max_speed abs(event-value))
+ max_speed = abs(event-value);
+
+ /*
+
Re: (another) Intel driver change needs testing.
On Mon, 17 May 2010 22:16:54 +0100 Owain Ainsworth zer...@googlemail.com wrote: The diff found at http://xenocara.org/xvmc.diff could do with some testing. This is some stuff that I didn't backport back to 2.9.1 when I did the intial intel driver backport pile. This contains a huge cleanup of the XVMC code (and enabled it on 965+ by default, it is still there by an option on lower). Otherwise there are a few small changes, but the vast majority of it is xvmc. With this the intel driver renderer is equal to just after intel 2.11 upstream. Please test and report to myself and matthieu@, good feedback or bad, when i've got this and one more thing out of the way I plan to work on radeon dri2. For those of you new here, or termnally adsent minded, instructions follow: make sure your xenocara tree is up to date. $ cd /usr/xenocara/driver/xf86-video-intel $ patch -E /path/to/xvmc.diff $ make -f Makefile.bsd-wrapper obj $ make -f Makefile.bsd-wrapper build restart X and robert is your mother's brother. Cheers, -0- -- Abstainer, n.: A weak person who yields to the temptation of denying himself a pleasure. -- Ambrose Bierce, The Devil's Dictionary Installed latest snapshot (from May 12, judging by the kernel), updated /usr/xenocara, applied patch, built the driver. Everything seems to be okay. After I enabled XVMC in xorg.conf, it says in Xorg.log that XVMC is enabled. Checked out the latest source of mplayer and built it with --enable-xvmc, this is what it says when I try to play a video with -vo xvmc: s...@d400:0:tmp$ /usr/local/mplayer-svn/bin/mplayer -vo xvmc video.mp4 MPlayer SVN-r31179-3.3.5 (C) 2000-2010 MPlayer Team Playing video.mp4. libavformat file format detected. Compiler did not align stack variables. Libavcodec has been miscompiled and may be very slow or crash. This is not a bug in libavcodec, but in the compiler. You may try recompiling using gcc = 4.2. Do not report crashes to FFmpeg developers. [lavf] stream 0: audio (aac), -aid 0, -alang und [lavf] stream 1: video (h264), -vid 0 VIDEO: [H264] 480x360 24bpp 25.000 fps 501.0 kbps (61.2 kbyte/s) Clip info: major_brand: mp42 minor_version: 0 compatible_brands: isomavc1mp42 vo_xvmc: X-Video extension 2.2 vo_xvmc: No X-Video MotionCompensation Extension on :0.0 Error opening/initializing the selected video_out (-vo) device. == Opening audio decoder: [faad] AAC (MPEG2/4 Advanced Audio Coding) AUDIO: 44100 Hz, 2 ch, s16le, 125.6 kbit/8.90% (ratio: 15698-176400) Selected audio codec: [faad] afm: faad (FAAD AAC (MPEG-2/MPEG-4 Audio)) == [AO OSS] audio_setup: Can't open audio device /dev/sound: Device busy ao2: 44100 Hz 2 chans s16le [0x9] [AO SUN] Can't open audio device /dev/audio, Device busy - nosound. DVB card number must be between 1 and 4 AO: [null] 44100Hz 2ch s16le (2 bytes per sample) Video: no video Starting playback... Exiting... (Quit) But from your mail to J. C. Roberts I gather it's supposed to be like this. Also, after your previous request to test GEM (like when we needed to recompile a kernel with an option), from some later snapshot onwards, I started having two problems: - Screen corruption, easiest way to get it was to scroll a webpage fast in Firefox, when this screen corruption happened -- errors would appear on the console from drm With this current software combination -- I don't see this problem anymore. - Second problem is that if I put something like `bgs image.jpg` in my .xinitrc, then when I run X, the background is never changed and remains to be that default X b/w pattern and the screen/window repainting gets completely messed up: the windows are simply not drawn. I run xterm, the cursor changes to text-cursor when I hover the mouse over the area where the window should be. I can start programs from this xterm, but the window is simply invisible. Same for any other program windows. My .xinitrc: bgs .fluxbox/backgrounds/space_005.jpg exec cwm If I comment out the bgs line, and run it manually after starting X, everything's fine. Also, I think this might be connected to this issue, when I type startx, when the mode is set and the screen is filled with X's default pattern, for approximately 0.4~0.6 seconds, in the lower right edge of the screen I see a black rectangle, about 1/3 of the screen's width and of ~4 pixels height, after that it disappears and I see the X pattern in this area as I normally should have. # dmesg# OpenBSD 4.7-current (GENERIC) #643: Wed May 12 02:00:04 MDT 2010 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Pentium(R) M processor
correction to video.4?
Not sure if this should be patched, since from what I understand, ioctl never has direct parameters, but always only pointers? Well, I didn't know that and I actually tried to pass an int, since descriptions of other ioctl's of this dev explicitly state that a pointer must be passed, but these said 'int'. Index: video.4 === RCS file: /cvs/src/share/man/man4/video.4,v retrieving revision 1.5 diff -u -r1.5 video.4 --- video.4 13 Sep 2008 05:37:12 - 1.5 +++ video.4 27 Apr 2010 23:45:10 - @@ -100,7 +100,7 @@ u_int32_t reserved[32]; }; .Ed -.It VIDIOC_S_INPUT (int) +.It VIDIOC_S_INPUT (int *) Select the current video input. .It VIDIOC_REQBUFS (struct v4l2_requestbuffers *) Initiate memory mapping or user pointer I/O. @@ -124,9 +124,9 @@ Remove a buffer from the queue. .Pp Same structure as for VIDIOC_REQBUFS. -.It VIDIOC_STREAMON (int) +.It VIDIOC_STREAMON (int *) Start video stream. -.It Dv VIDIOC_STREAMOFF (int) +.It Dv VIDIOC_STREAMOFF (int *) Stop video stream. .It VIDIOC_TRY_FMT (struct v4l2_format *) Try a data format.
Re: New intel X driver requires testing.
DELL Latitude D400 laptop reporting in! At first, I accidentally compiled the kernel without the GEM option, as a result, when I ran X, the screen just went black, and even when I killed the server through ssh, the screen never recovered. Everything seems to be working ok. I played with Mplayer a bit and noticed that the good old 'stroboscopy' video was still there. I.e. when there is a lot of motion, the video kinda like slows down periodically (each second or so) and then goes to normal, possibly dropping some frames or effectively dropping them by playing the frames which are being late very fast so that the brain doesn't have a chance to perceive them. Then it occured to me to try Mplayer's -nosound option, and the video then played real smoothly. Then I `pkill aucat` and tried playing the video again, it was just as smooth as with '-nosound'. Here's a video which demonstrates the effect: (I suggest watching it with aucat not running, since if it does the same effect for you, you won't be able to see the difference) http://yy.lv/download.php?f=122601 first, the video is played with mplayer's -nosound option then, `aucat -l` is started and the video is played finally, `pkill aucat` and the video is played This problem, 'stroboscopic' video when there's a lot of motion, has been bugging me for a long time now, as long as I can remember in fact. So I can't really tell whether earlier it was due to bad performance of the video drivers or because of aucat, since it never occured to me before to try -nosound. Attached are X.log, outputs from xrandr, xdpyinfo, xvinfo, glxinfo and dmesg. (--) checkDevMem: using aperture driver /dev/xf86 (--) Using wscons driver on /dev/ttyC4 in pcvt compatibility mode (version 3.32) X.Org X Server 1.6.5 Release Date: 2009-10-11 X Protocol Version 11, Revision 0 Build Operating System: OpenBSD 4.7 i386 Current Operating System: OpenBSD d400 4.7 GENERIC_d400#4 i386 Build Date: 10 April 2010 02:25:07AM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Sat Apr 17 12:48:45 2010 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout X.org Configured (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device Card0 (**) |--Input Device Mouse0 (**) |--Input Device Keyboard0 (**) Option BlankTime 0 (**) Option StandbyTime 0 (**) Option SuspendTime 0 (**) Option OffTime 10 (==) Not automatically adding devices (==) Not automatically enabling devices (WW) The directory /usr/local/lib/X11/fonts/jmk/ does not exist. Entry deleted from font path. (WW) The directory /usr/local/lib/X11/fonts/artwiz-aleczapka does not exist. Entry deleted from font path. (WW) The directory /usr/local/lib/X11/fonts/hack does not exist. Entry deleted from font path. (**) FontPath set to: /usr/X11R6/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/mscorefonts, /usr/local/lib/X11/fonts/terminus, /usr/local/lib/X11/fonts/local, /usr/X11R6/lib/X11/fonts/TTF/, /usr/X11R6/lib/X11/fonts/OTF, /usr/X11R6/lib/X11/fonts/Type1/, /usr/X11R6/lib/X11/fonts/100dpi/, /usr/X11R6/lib/X11/fonts/75dpi/, /usr/X11R6/lib/X11/fonts/misc/, /usr/X11R6/lib/X11/fonts/TTF/, /usr/X11R6/lib/X11/fonts/OTF, /usr/X11R6/lib/X11/fonts/Type1/, /usr/X11R6/lib/X11/fonts/100dpi/, /usr/X11R6/lib/X11/fonts/75dpi/ (**) ModulePath set to /usr/X11R6/lib/modules (II) Loader magic: 0x7ec0 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 5.0 X.Org XInput driver : 4.0 X.Org Server Extension : 2.0 (II) Loader running on openbsd (--) PCI:*(0:0:2:0) 8086:3582:1028:0139 Intel 82855GM Video rev 2, Mem @ 0xf000/134217728, 0xfaf8/524288, I/O @ 0xc000/8 (--) PCI: (0:0:2:1) 8086:3582:1028:0139 Intel 82855GM Video rev 2, Mem @ 0xe800/134217728, 0xfaf0/524288 (II) System resource ranges: [0] -1 0 0x000f - 0x000f (0x1) MX[B] [1] -1 0 0x000c - 0x000e (0x3) MX[B] [2] -1 0 0x - 0x0009 (0xa) MX[B] [3] -1 0 0x - 0x (0x1) IX[B] [4] -1 0 0x - 0x00ff (0x100) IX[B] (II) extmod will be loaded. This was enabled by default and also specified in the config file. (II) dbe will be loaded. This was enabled by default and also specified in the config file. (II) glx will be loaded. This was enabled by default and also specified in the config file. (II) dri will be loaded. This was enabled by default and also specified in the config file. (II) dri2 will be loaded by default. (II) LoadModule:
Re: drm for r600 and r700
On Sat, 10 Apr 2010 00:35:09 +0100
Owain Ainsworth zer...@googlemail.com wrote:
On Sat, Apr 10, 2010 at 02:24:43AM +0300, Sviatoslav Chagaev wrote:
On Wed, 24 Mar 2010 02:28:24 +
Owain Ainsworth zer...@googlemail.com wrote:
This diff doesn't have all of the pcidevs that it could have (if it
doesn't attach on your hardware send me the output of pcidump -v and I
will send an extra diff). However, this gives radeondrm(4) the right
bits to work on newer (r600 and r700) chipsets.
Please test and report back to me. It should give you 2d acceleration and
XVideo.
Cheers,
-0-
(dmesg is attached in the end)
I installed the latest snapshot of amd64, then
cd /usr/src
cvs up
added 4850 to radeon_drv.c
May I see the diff for that, please? to check it was correct. I will
then commit it.
s...@x2:0:/usr/src/sys/dev/pci/drm$ cvs diff -u
cvs server: Diffing .
Index: radeon_drv.c
===
RCS file: /OpenBSD/src/sys/dev/pci/drm/radeon_drv.c,v
retrieving revision 1.39
diff -u -r1.39 radeon_drv.c
--- radeon_drv.c1 Apr 2010 23:24:54 - 1.39
+++ radeon_drv.c9 Apr 2010 23:59:39 -
@@ -505,6 +505,8 @@
CHIP_RV710|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD4650,
CHIP_RV730|RADEON_NEW_MEMMAP},
+ {PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD4850,
+ CHIP_RV770|RADEON_NEW_MEMMAP},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD4870,
CHIP_RV770|RADEON_NEW_MEMMAP},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD4890,
s...@x2:0:/usr/src/sys/dev/pci/drm$
and disabled a driver, called 'udl' in
GENERIC, because it depended on some .c files which should've been
located in a nonexistent directory (dev/videomode) and compiled an MP
kernel.
Your kernel tree is hosed. videomode does exist, as does udl.
Oops
snip radeonhd X log and explanation
Unless it currently fixes a bug in the radeon driver for you, I would
generally recommend that everyone avoid radeonhd. It is essentially dead
upstream will all developement going into the radeon driver. Our in tree
version of radeon is a little old but hopefully will be updated in the
near future.
Oh, okay. I somehow always thought that 'radeonhd' was a sort of an
'enhanced' version of radeon driver with more features... Must be the
hypnotizing effect of the 'hd' letters =)
I see now that it is irrelevant, but since I originally wanted to also
post the output from Xorg -configure but forgot to do so, here it is:
X.Org X Server 1.6.5
Release Date: 2009-10-11
X Protocol Version 11, Revision 0
Build Operating System: OpenBSD 4.7 amd64
Current Operating System: OpenBSD x2.my.domain 4.7 GENERIC.MP.x2#0 amd64
Build Date: 06 April 2010 08:22:11AM
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: /var/log/Xorg.0.log, Time: Sat Apr 10 00:45:44 2010
List of video drivers:
apm
ark
ati
chips
cirrus
dummy
glint
i128
intel
mach64
mga
neomagic
nv
openchrome
r128
radeon
radeonhd
rendition
s3
s3virge
savage
siliconmotion
sis
tdfx
trident
tseng
voodoo
vmware
wsudl
geode
i740
vesa
Xorg:/usr/X11R6/lib/modules/drivers/radeonhd_drv.so:
/usr/X11R6/lib/modules/drivers/radeon_drv.so : WARNING:
symbol(AtomBiosRequestList) size mismatch, relink your program
dlopen: File not an ELF object
(EE) Failed to load /usr/X11R6/lib/modules/drivers//voodoo_drv.so
(EE) Failed to load module voodoo (loader failed, 7)
dlopen: File not an ELF object
(EE) Failed to load /usr/X11R6/lib/modules/drivers//geode_drv.so
(EE) Failed to load module geode (loader failed, 7)
dlopen: File not an ELF object
(EE) Failed to load /usr/X11R6/lib/modules/drivers//i740_drv.so
(EE) Failed to load module i740 (loader failed, 7)
(++) Using config file: /root/xorg.conf.new
Xorg detected your mouse at device /dev/wsmouse.
Please check your config if the mouse is still not
operational, as by default Xorg tries to autodetect
the protocol.
Your xorg.conf file is /root/xorg.conf.new
To test the server, run 'X -config /root/xorg.conf.new'
It chooses 'radeon' as the driver.
[patch] fix a few ksh auto-completion bugs
Greetings and felicitations!
Two things about auto-completion annoyed me in ksh for almost 4 years:
( `|' shows the position of cursor after auto-completion)
1) tilde bug:
$ ls ~/nonexistTAB
$ ls ~/nonexist\* |
(i.e. it expands to something insensible, instead of doing nothing like
in /home/your_user_name/nonexist case)
2) square bracket bug:
$ touch 'so[me]_file'
$ ls so\[TAB
$ ls so\[|
(i.e. nothing happens)
behavior after the patch:
1)
$ ls ~/nonexistTAB
$ ls ~/nonexist|
2)
$ ls so[TAB
$ ls so\[me\]_file |
(it should work for all kinds of auto-completions, and both
in vi and emacs mode)
While I was testing to see if I broke something by fixing these two,
I also discovered that auto-completions now work in much more sensible
and useful way for strings with variables:
before patch:
$ ls -d tmp
$ tmp
$ ls $HOME/tmTAB
$ ls /home/s/tm |
after patch:
$ ls $HOME/tmTAB
$ ls /home/s/tmp/|
make test -- shows no errors.
Patch:
Index: edit.c
===
RCS file: /OpenBSD/src/bin/ksh/edit.c,v
retrieving revision 1.33
diff -r1.33 edit.c
414c414
expand(yylval.cp, w, DOGLOB|DOTILDE|DOMARKDIRS);
---
expand(yylval.cp, w, DOCOMPLETION|DOGLOB|DOTILDE|DOMARKDIRS);
487c487
pat = evalstr(toglob, DOPAT|DOTILDE);
---
pat = evalstr(toglob, DOCOMPLETION|DOPAT|DOTILDE);
650c650
/* Given a string, copy it and possibly add a '*' to the end. The
---
/* Given a string, copy it and add a '*' to the end. The
657,658d656
char *s;
bool saw_slash = false;
663,684c661,663
toglob = str_nsave(str, slen + 1, ATEMP); /* + 1 for * */
toglob[slen] = '\0';
/*
* If the pathname contains a wildcard (an unquoted '*',
* '?', or '[') or parameter expansion ('$'), or a ~username
* with no trailing slash, then it is globbed based on that
* value (i.e., without the appended '*').
*/
for (s = toglob; *s; s++) {
if (*s == '\\' s[1])
s++;
else if (*s == '*' || *s == '[' || *s == '?' || *s == '$'
|| (s[1] == '(' /*)*/ strchr(*...@!, *s)))
break;
else if (*s == '/')
saw_slash = true;
}
if (!*s (*toglob != '~' || saw_slash)) {
toglob[slen] = '*';
toglob[slen + 1] = '\0';
}
---
toglob = str_nsave(str, slen + 1, ATEMP);
toglob[slen] = '*';
toglob[slen + 1] = '\0';
Index: eval.c
===
RCS file: /OpenBSD/src/bin/ksh/eval.c,v
retrieving revision 1.34
diff -r1.34 eval.c
557c557
glob(p, wp, f DOMARKDIRS);
---
glob(p, wp, f (DOCOMPLETION |
DOMARKDIRS));
599c599
if (f (DOPAT | DOGLOB)) {
---
if (!(f DOCOMPLETION) f (DOPAT |
DOGLOB)) {
606d605
case '*':
607a607,610
if (f DOCOMPLETION)
break;
/* fall through */
case '*':
617,620c620,624
if ((f DOBRACE_) (c == OBRACE ||
(fdo DOBRACE_))) {
fdo |= DOBRACE_|DOMAGIC_;
*dp++ = MAGIC;
---
if (!(f DOCOMPLETION)
(f DOBRACE_)
(c == OBRACE || (fdo
DOBRACE_))) {
fdo |=
DOBRACE_|DOMAGIC_;
*dp++ = MAGIC;
936c940
glob(char *cp, XPtrV *wp, int markdirs)
---
glob(char *cp, XPtrV *wp, int flags)
940,942c944,947
if (glob_str(cp, wp, markdirs) == 0)
XPput(*wp, debunk(cp, cp, strlen(cp) + 1));
else
---
if (glob_str(cp, wp, flags DOMARKDIRS) == 0) {
if (!(flags DOCOMPLETION))
XPput(*wp, debunk(cp, cp, strlen(cp) + 1));
} else
1144,1145c1149,1150
return dp;
memcpy(dp, sp, s - sp);
---
return dp;
memmove(dp, sp, s - sp);
Index: tree.h
===
RCS file: /OpenBSD/src/bin/ksh/tree.h,v
retrieving revision 1.10
diff -r1.10 tree.h
128a129
#define DOCOMPLETION BIT(11) /* hint that we are doing an auto-completion */
Re: [patch] fix a few ksh auto-completion bugs
On Wed, 3 Mar 2010 18:14:51 -0500
Brad b...@comstyle.com wrote:
On Thursday 04 March 2010 03:00:03 Sviatoslav Chagaev wrote:
Greetings and felicitations!
Ensure the diffs are created as a unified diff (.e.g. cvs diff -upRN) if
you actually want anyone to look at them ;)
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Ok, sorry:
Index: edit.c
===
RCS file: /OpenBSD/src/bin/ksh/edit.c,v
retrieving revision 1.33
diff -u -p -r1.33 edit.c
--- edit.c 2 Aug 2007 10:50:25 - 1.33
+++ edit.c 3 Mar 2010 23:20:14 -
@@ -411,7 +411,7 @@ x_file_glob(int flags, const char *str,
}
source = sold;
XPinit(w, 32);
- expand(yylval.cp, w, DOGLOB|DOTILDE|DOMARKDIRS);
+ expand(yylval.cp, w, DOCOMPLETION|DOGLOB|DOTILDE|DOMARKDIRS);
XPput(w, NULL);
words = (char **) XPclose(w);
@@ -484,7 +484,7 @@ x_command_glob(int flags, const char *st
toglob = add_glob(str, slen);
/* Convert foo* (toglob) to a pattern for future use */
- pat = evalstr(toglob, DOPAT|DOTILDE);
+ pat = evalstr(toglob, DOCOMPLETION|DOPAT|DOTILDE);
afree(toglob, ATEMP);
XPinit(w, 32);
@@ -647,41 +647,20 @@ x_cf_glob(int flags, const char *buf, in
return nwords;
}
-/* Given a string, copy it and possibly add a '*' to the end. The
+/* Given a string, copy it and add a '*' to the end. The
* new string is returned.
*/
static char *
add_glob(const char *str, int slen)
{
char *toglob;
- char *s;
- bool saw_slash = false;
if (slen 0)
return (char *) 0;
- toglob = str_nsave(str, slen + 1, ATEMP); /* + 1 for * */
- toglob[slen] = '\0';
-
- /*
-* If the pathname contains a wildcard (an unquoted '*',
-* '?', or '[') or parameter expansion ('$'), or a ~username
-* with no trailing slash, then it is globbed based on that
-* value (i.e., without the appended '*').
-*/
- for (s = toglob; *s; s++) {
- if (*s == '\\' s[1])
- s++;
- else if (*s == '*' || *s == '[' || *s == '?' || *s == '$'
-|| (s[1] == '(' /*)*/ strchr(*...@!, *s)))
- break;
- else if (*s == '/')
- saw_slash = true;
- }
- if (!*s (*toglob != '~' || saw_slash)) {
- toglob[slen] = '*';
- toglob[slen + 1] = '\0';
- }
+ toglob = str_nsave(str, slen + 1, ATEMP);
+ toglob[slen] = '*';
+ toglob[slen + 1] = '\0';
return toglob;
}
Index: eval.c
===
RCS file: /OpenBSD/src/bin/ksh/eval.c,v
retrieving revision 1.34
diff -u -p -r1.34 eval.c
--- eval.c 29 Jan 2009 23:27:26 - 1.34
+++ eval.c 3 Mar 2010 23:20:14 -
@@ -554,7 +554,7 @@ expand(char *cp,/* input word */
else
#endif /* BRACE_EXPAND */
if (fdo DOGLOB)
- glob(p, wp, f DOMARKDIRS);
+ glob(p, wp, f (DOCOMPLETION |
DOMARKDIRS));
else if ((f DOPAT) || !(fdo DOMAGIC_))
XPput(*wp, p);
else
@@ -596,15 +596,18 @@ expand(char *cp, /* input word */
* to have magic !,-,]'s outside of
* [...] expressions.
*/
- if (f (DOPAT | DOGLOB)) {
+ if (!(f DOCOMPLETION) f (DOPAT |
DOGLOB)) {
fdo |= DOMAGIC_;
if (c == '[')
fdo |= f DOGLOB;
*dp++ = MAGIC;
}
break;
- case '*':
case '?':
+ if (f DOCOMPLETION)
+ break;
+ /* fall through */
+ case '*':
if (f (DOPAT | DOGLOB)) {
fdo |= DOMAGIC_ | (f DOGLOB);
*dp++ = MAGIC;
@@ -614,10 +617,11 @@ expand(char *cp, /* input word */
case OBRACE:
case ',':
case CBRACE
