CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: r...@cvs.openbsd.org2009/08/31 12:01:01 Modified files: net/dnsmasq: Makefile net/dnsmasq/patches: patch-src_tftp_c Log message: Security fix for CVE-2009-2957,2958 ok jasper@
Re: CVS: cvs.openbsd.org: ports
On Mon, Aug 31, 2009 at 12:51:02PM -0600, Matthias Kilian wrote: CVSROOT: /cvs Module name: ports Changes by: k...@cvs.openbsd.org2009/08/31 12:51:02 Modified files: x11/kde/graphics3: Makefile Log message: Fix some WANTLIB and LIB_DEPENDS typos, unbreaking this and saving ajacoutot's mailbox beeing flooded with complaints. Bump all, because I'm lazy. Tweaks and ok, ajacoutot@ and ok, jasper@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2009/08/31 13:00:01 Modified files: www/webkit : Makefile Log message: WANTLIB += pthread-stubs xcb, and bump. How could I miss this one?
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2009/08/31 14:48:56 Modified files: x11/pinot : Makefile Log message: - add missing build dependency ok ajacoutot@ (MAINTAINER)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2009/08/31 14:52:29 Modified files: net/zabbix : Makefile Log message: - add jabber notification support ok ajacoutot@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: merd...@cvs.openbsd.org 2009/08/31 17:05:57 Modified files: www/wordpress : Makefile distinfo Removed files: www/wordpress/patches: patch-wp-login_php Log message: Update to 2.8.4. Remove patch that was included in 2.8.4. Remove pre-configure target that searched for *.orig files. ok sthen@, martynas@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2009/08/31 17:51:21 Modified files: mail/p5-Mail-SPF-Iterator: Makefile distinfo Log message: update Mail-SPF-Iterator to 1.07
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fg...@cvs.openbsd.org 2009/08/31 19:29:02 Modified files: security/py-paramiko: Makefile distinfo security/py-paramiko/pkg: PLIST Log message: Update to 1.7.5. benoit@ ok
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fg...@cvs.openbsd.org 2009/08/31 19:51:55 Modified files: x11: Makefile Added files: x11/compiz : Makefile Log message: enter compiz/core
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fg...@cvs.openbsd.org 2009/08/31 20:14:52 Modified files: x11/compiz/core: Makefile Log message: fix wantlib.
ports/dev ports/deve?
Hi! What is the point of the ports/dev and ports/deve directories? Are these typos? Daniel -- LÉVAI Dániel PGP key ID = 0x4AC0A4B1 Key fingerprint = D037 03B9 C12D D338 4412 2D83 1373 917A 4AC0 A4B1
Re: javascript
On 2009/08/31 08:59, igor denisov wrote: Hello there, I tried links+-2.2 on www.netaddress.com and it turned out that I cannot read my email, though links.conf read enable-javascript 1 why is that so? from their changelog: Mon Apr 16 01:49:07 MET DST 2007 mikulas: Javascript was removed. The reason is that it is very buggy, Martin Pergel doesn't have time to develop it and code is so messy that no one else can understand it.
Re: ports/dev ports/deve?
On Mon, Aug 31, 2009 at 11:13:43AM +0200, LEVAI Daniel wrote: Hi! What is the point of the ports/dev and ports/deve directories? Are these typos? I think so. CVS still makes directories that are non-existent (but once existed) unless you use -P. -- Best Regards Edd Barrett (Freelance software developer / technical writer / open-source developer) http://students.dec.bmth.ac.uk/ebarrett
Re: ports/dev ports/deve?
On Monday 31 August 2009 11.27.07 you wrote: On Mon, Aug 31, 2009 at 11:13:43AM +0200, LEVAI Daniel wrote: Hi! What is the point of the ports/dev and ports/deve directories? Are these typos? I think so. CVS still makes directories that are non-existent (but once existed) unless you use -P. These directories exist in the cvs repo, not in my working copy. Maybe someone should cvs rm ports/deve ports/dev; cvs commit? Daniel -- LÉVAI Dániel PGP key ID = 0x4AC0A4B1 Key fingerprint = D037 03B9 C12D D338 4412 2D83 1373 917A 4AC0 A4B1
Re: ports/dev ports/deve?
On 2009/08/31 11:36, LEVAI Daniel wrote: On Monday 31 August 2009 11.27.07 you wrote: On Mon, Aug 31, 2009 at 11:13:43AM +0200, LEVAI Daniel wrote: Hi! What is the point of the ports/dev and ports/deve directories? Are these typos? I think so. CVS still makes directories that are non-existent (but once existed) unless you use -P. These directories exist in the cvs repo, not in my working copy. Maybe someone should cvs rm ports/deve ports/dev; cvs commit? You can't remove directories using cvs.
Re: mplayer
On Sun, Aug 30, 2009 at 02:41:32PM +0200, Marc Espie wrote: On Tue, Aug 25, 2009 at 02:47:02AM +, Jacob Meuser wrote: On Mon, Aug 24, 2009 at 06:23:46PM +0100, Mikolaj Kucharski wrote: On Mon, Aug 24, 2009 at 04:51:49PM +, Jacob Meuser wrote: could we move the support for win32/real/qtx codecs to a flavor? currently, one has to have machdep.userldt enabled to play WMV/WMA files, even if mplayer doesn't really need to load the codecs to play the files. this is because when mplayer is built with support for the binary codecs, it tries to probe the codecs when opening a WMV/WMA file. then mplayer exists asking you to enable machdep.userldt. this doesn't happen if mplayer is built without support for the binary codecs. it just plays the files. Does that mean that binary codecs have precedence before other codecs? What happends if you change order of vfm/afm in config? I would prefer to have it enabled by default. I really don't think it's a good idea to mess with mplayer internals. either a win32, or if most people really really want them by default, a no_win32 flavor. let's keep it simple, please. More flavors is not more simple. Just the contrary. Especially when you have to deal with twice as many error reports... It also means users have to make choices as to which flavor they install. And this grows bulk build times as well. Can we just stay away from flavors and fix this for real ? fuck it then. I'm happy with my local update of mplayer. I'm not the maintainer of this port anyway. good luck. -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: mplayer
On 2009/08/31 09:58, Jacob Meuser wrote: On Sun, Aug 30, 2009 at 02:41:32PM +0200, Marc Espie wrote: On Tue, Aug 25, 2009 at 02:47:02AM +, Jacob Meuser wrote: On Mon, Aug 24, 2009 at 06:23:46PM +0100, Mikolaj Kucharski wrote: On Mon, Aug 24, 2009 at 04:51:49PM +, Jacob Meuser wrote: could we move the support for win32/real/qtx codecs to a flavor? currently, one has to have machdep.userldt enabled to play WMV/WMA files, even if mplayer doesn't really need to load the codecs to play the files. this is because when mplayer is built with support for the binary codecs, it tries to probe the codecs when opening a WMV/WMA file. then mplayer exists asking you to enable machdep.userldt. this doesn't happen if mplayer is built without support for the binary codecs. it just plays the files. Does that mean that binary codecs have precedence before other codecs? What happends if you change order of vfm/afm in config? I would prefer to have it enabled by default. I really don't think it's a good idea to mess with mplayer internals. either a win32, or if most people really really want them by default, a no_win32 flavor. let's keep it simple, please. More flavors is not more simple. Just the contrary. Especially when you have to deal with twice as many error reports... It also means users have to make choices as to which flavor they install. And this grows bulk build times as well. Can we just stay away from flavors and fix this for real ? fuck it then. I'm happy with my local update of mplayer. I'm not the maintainer of this port anyway. good luck. fwiw, I'd be totally happy not adding a flavour and just disabling the binary codecs outright, it used to be needed in order to play a significant number of files, but native codec support is pretty reasonable now, I don't think we need to keep on encouraging people to use the untrusted, binary-only, and almost certainly insecure codecs.
Re: mplayer
On Mon, 31 Aug 2009, Stuart Henderson wrote: fwiw, I'd be totally happy not adding a flavour and just disabling the binary codecs outright, it used to be needed in order to play a significant number of files, but native codec support is pretty reasonable now, I don't think we need to keep on encouraging people to use the untrusted, binary-only, and almost certainly insecure codecs. I concur. -- Antoine
NEW ports: libev and i3
Hi, This are my first ports for OpenBSD : i3 a tiling window manager inspired by wmii and libev which i3 depends on. Hope I didn't make to much mistakes, you can find them here : http://www.etoilebsd.net/~bapt/i3.tar.gz which goes in x11 category and http://www.etoilebsd.net/~bapt/libev.tar.gz which goes in devel category regards, bapt
Re: mplayer
From owner-ports+m37...@openbsd.org Mon Aug 31 13:30:33 2009 Date: Mon, 31 Aug 2009 11:22:45 +0100 From: Stuart Henderson st...@openbsd.org To: ports@openbsd.org Subject: Re: mplayer On 2009/08/31 09:58, Jacob Meuser wrote: On Sun, Aug 30, 2009 at 02:41:32PM +0200, Marc Espie wrote: On Tue, Aug 25, 2009 at 02:47:02AM +, Jacob Meuser wrote: On Mon, Aug 24, 2009 at 06:23:46PM +0100, Mikolaj Kucharski wrote: On Mon, Aug 24, 2009 at 04:51:49PM +, Jacob Meuser wrote: could we move the support for win32/real/qtx codecs to a flavor? currently, one has to have machdep.userldt enabled to play WMV/WMA files, even if mplayer doesn't really need to load the codecs to play the files. this is because when mplayer is built with support for the binary codecs, it tries to probe the codecs when opening a WMV/WMA file. then mplayer exists asking you to enable machdep.userldt. this doesn't happen if mplayer is built without support for the binary codecs. it just plays the files. Does that mean that binary codecs have precedence before other codecs? What happends if you change order of vfm/afm in config? I would prefer to have it enabled by default. I really don't think it's a good idea to mess with mplayer internals. either a win32, or if most people really really want them by default, a no_win32 flavor. let's keep it simple, please. More flavors is not more simple. Just the contrary. Especially when you have to deal with twice as many error reports... It also means users have to make choices as to which flavor they install. And this grows bulk build times as well. Can we just stay away from flavors and fix this for real ? fuck it then. I'm happy with my local update of mplayer. I'm not the maintainer of this port anyway. good luck. fwiw, I'd be totally happy not adding a flavour and just disabling the binary codecs outright, it used to be needed in order to play a significant number of files, but native codec support is pretty reasonable now, I don't think we need to keep on encouraging people to use the untrusted, binary-only, and almost certainly insecure codecs. I never needed proprietary codecs; and if it gets in the way for ffwma/ffwmv i'm happy with disabling them.
Re: ports/dev ports/deve?
These directories exist in the cvs repo, not in my working copy. Maybe someone should cvs rm ports/deve ports/dev; cvs commit? You can't remove directories using cvs. That is right and still there are options. Export the WHOLE CVS-stuff to a system which allows you to remove these folders and then re-export it to a new CVS-Repo which replaces then the old one. Thus you delete folders Stuart and keep comments/messages... Or you might hack opencvs to allow this. Would be cool... Regards, Gandalf
Re: xstatbar
Works fine to me (new package), in a OpenBSD 4.5 (Thinkpad R61i). 2009/8/30 Ryan Flannery ryan.flann...@gmail.com: On Sun, Aug 30, 2009 at 8:55 PM, Brynetbry...@gmail.com wrote: Edd wrote: Upon invocation I get: xstatbar: ioctl AUDIO_MIXER_READ: Invalid argument The system I was using had no sound card.. I assumed this error was related to that, so perhaps the author can tell us why it doesn't work? Here is the cosmetic changes anyway, sorry for not properly testing. Off-hand I have no idea why this fails, but I can dig into it further if it is still an open issue.
Re: mplayer
On Mon, Aug 31, 2009 at 12:27:01PM +0200, Antoine Jacoutot wrote: On Mon, 31 Aug 2009, Stuart Henderson wrote: fwiw, I'd be totally happy not adding a flavour and just disabling the binary codecs outright, it used to be needed in order to play a significant number of files, but native codec support is pretty reasonable now, I don't think we need to keep on encouraging people to use the untrusted, binary-only, and almost certainly insecure codecs. I concur. I'll check what my video collection says, and if there's still a significant number of thingies that need the binary codecs.
Re: ports/dev ports/deve?
On Mon, Aug 31, 2009 at 01:15:53PM +0200, paranoid.gand...@googlemail.com wrote: These directories exist in the cvs repo, not in my working copy. Maybe someone should cvs rm ports/deve ports/dev; cvs commit? You can't remove directories using cvs. That is right and still there are options. Export the WHOLE CVS-stuff to a system which allows you to remove these folders and then re-export it to a new CVS-Repo which replaces then the old one. Thus you delete folders Stuart and keep comments/messages... Or you might hack opencvs to allow this. Would be cool... Talk is cheap. Helping people finish opencvs would be cooler.
Re: xstatbar
Ryan Flannery wrote: 1. Brynet: you said you don't have a sound card. Do you really get the same error Edd listed? I would have expected it to error, but with a different message. Whoops, my bad.. the system had an integraded sound card, so the error was the same as Edd's. I'm using OpenBSD 4.5. auvia0 at pci0 dev 17 function 5 VIA VT8233 AC97 rev 0x50: apic 2 int 22 (irq 4) ac97: codec id 0x41445370 (Analog Devices AD1980) ac97: codec features headphone, 20 bit DAC, No 3D Stereo audio0 at auvia0 Attached are the logs you wanted. -Brynet 0: 'inputs' 1: 'outputs' 2: 'record' 3: 'master' 4: 'mute' 5: 'mono' 6: 'mute' 7: 'source' 8: 'hp' 9: 'mute' 10: 'surround' 11: 'mute' 12: 'center' 13: 'mute' 14: 'lfe' 15: 'mute' 16: 'spkr' 17: 'mute' 18: 'phone' 19: 'mute' 20: 'mic' 21: 'mute' 22: 'preamp' 23: 'source' 24: 'line' 25: 'mute' 26: 'cd' 27: 'mute' 28: 'video' 29: 'mute' 30: 'aux' 31: 'mute' 32: 'dac' 33: 'mute' 34: 'source' 35: 'volume' 36: 'mute' 37: 'extamp' 38: 'spdif' xstatbar: ioctl AUDIO_MIXER_READ (init, read-cur): Invalid argument outputs.master=255,255 outputs.master.mute=off outputs.mono=255 outputs.mono.mute=on outputs.mono.source=mixerout outputs.hp=255,255 outputs.hp.mute=on outputs.surround=255,255 outputs.surround.mute=off outputs.center=255 outputs.center.mute=off outputs.lfe=255 outputs.lfe.mute=off inputs.spkr=255 inputs.spkr.mute=off inputs.phone=7 inputs.phone.mute=on inputs.mic=7 inputs.mic.mute=on inputs.mic.preamp=off inputs.mic.source=mic0 inputs.line=7,7 inputs.line.mute=on inputs.cd=191,191 inputs.cd.mute=off inputs.video=255,255 inputs.video.mute=off inputs.aux=7,7 inputs.aux.mute=on inputs.dac=191,191 inputs.dac.mute=off record.source=mic record.volume=15,15 record.volume.mute=on outputs.extamp=on outputs.spdif=off
Kylie, can't wait to see you again!
Hey Kylie, How I loove your new brazilian waxing ;) When will we meet again? Can't wait! What about tomorrow night? By the way, have you seen this video on Youtube: http://www.youtube.com/watch?v=w6-S-HjeTyU Really low-budget, but a nice idea. What do you as a marketing pro think about it? CU Josh
Re: mplayer
On Mon, Aug 31, 2009 at 4:27 AM, Antoine Jacoutotajacou...@bsdfrog.org wrote: On Mon, 31 Aug 2009, Stuart Henderson wrote: fwiw, I'd be totally happy not adding a flavour and just disabling the binary codecs outright, it used to be needed in order to play a significant number of files, but native codec support is pretty reasonable now, I don't think we need to keep on encouraging people to use the untrusted, binary-only, and almost certainly insecure codecs. I concur. +1 i've been on amd64 for a couple of years now, so i can't use the win32 codecs. i haven't found anything worth watching in recent memory that at least one of mplayer, ffplay or xine couldn't handle. -- GDB has a 'break' feature; why doesn't it have 'fix' too?
Re: xstatbar
On Sun, Aug 30, 2009 at 09:35:08PM -0400, Ryan Flannery wrote:
On Sun, Aug 30, 2009 at 8:55 PM, Brynetbry...@gmail.com wrote:
Edd wrote:
Upon invocation I get:
xstatbar: ioctl AUDIO_MIXER_READ: Invalid argument
The system I was using had no sound card.. I assumed this error was
related to that, so perhaps the author can tell us why it doesn't
work?
Here is the cosmetic changes anyway, sorry for not properly testing.
Off-hand I have no idea why this fails, but I can dig into it further
if it is still an open issue.
couple issues here ...
/* find the master device */
v-master_idx = -1;
devinfo.index = 0;
while (ioctl(v-dev_fd, AUDIO_MIXER_DEVINFO, devinfo) = 0)
{ if (strncmp(devinfo.label.name, master, 7) == 0)
v-master_idx = devinfo.index;
devinfo.index++;
}
if (v-master_idx == -1)
errx(1, failed to find \master\ mixer device for volume init);
you should make sure you get outputs.master as opposed to possibly
record.master, or some other master. technically speaking, a device
is free to make up whatever class it wants. you have to find the
outputs class index, and make sure that master's mixer_class equals
the outputs class index.
/* Volume values are stored as 8-bit values, however not all values are
* supported (i.e. fewer than 256 different volume levels may be
* supported). As such, to accurately determine the percentages shown
* in the display, we have to find the maximum settings for this
* device.
you could use the delta: devinfo.un.v.delta. that is the step size
of the hardware. that is, you have to move that many volume units to
affect a change in the hardware. you could use this to determine
the largest value ...
So, we...
*1. read the current volume values
*2. set the volume to the max possible (255)
255 - AUDIO_MAX_GAIN
*3. read the volume values and see what the max is for this device
*4. reset the volume to what was read in step 1 so we don't muck
* with the users' volume.
*/
/* read current volume */
v-info.dev = v-master_idx;
v-info.type = AUDIO_MIXER_VALUE;
if (ioctl(v-dev_fd, AUDIO_MIXER_READ, (v-info)) 0)
err(1, ioctl AUDIO_MIXER_READ);
that fails because on many devices because num_channels is not set
correctly. in sys/dev/ic/ac97.c:
ac97_mixer_get_port(struct ac86_codec_if *codec_if, mixer_ctrl_t *cp)
{
struct ac97_softc *as = (struct ac97_softc *)codec_if;
struct ac97_source_info *si = as-source_info[cp-dev];
...
case AUDIO_MIXER_VALUE:
{
const struct audio_mixer_value *value = si-info;
u_int16_t l, r;
if ((cp-un.value.num_channels = 0) ||
(cp-un.value.num_channels value-num_channels))
return (EINVAL);
here, value-num_channels == devinfo.un.v.num_channels ...
--
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
Re: xstatbar
On Mon, Aug 31, 2009 at 10:43:26PM +, Jacob Meuser wrote: if (v-master_idx == -1) errx(1, failed to find \master\ mixer device for volume init); you should make sure you get outputs.master as opposed to possibly record.master, or some other master. technically speaking, a device is free to make up whatever class it wants. you have to find the outputs class index, and make sure that master's mixer_class equals the outputs class index. also, there is no guarantee that outputs.master exists on any given device. you may want to also try inputs.dac, outputs.dac and outputs.outputs, in that order. -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
openports.se
Is the maintainer of this out for holiday? It's not been updated since 18 Aug. I really like it because I can see the updates at a glance at work, which is not possible via cvs (blocked at work). Regards, Bryan
Re: xstatbar
On Mon, Aug 31, 2009 at 11:25:19PM -0400, Ryan Flannery wrote:
Hi Jacob,
Many thanks for your comments. They've saved me at least a couple of
hours of digging (though prompted some more!)
If you wouldn't mind and have the time, I have a few questions...
On Mon, Aug 31, 2009 at 6:43 PM, Jacob Meuserjake...@sdf.lonestar.org wrote:
couple issues here ...
? /* find the master device */
? v-master_idx = -1;
? devinfo.index = 0;
? while (ioctl(v-dev_fd, AUDIO_MIXER_DEVINFO, devinfo) = 0)
? { ?if (strncmp(devinfo.label.name, master, 7) == 0)
? ? ? ? v-master_idx = devinfo.index;
? ? ?devinfo.index++;
? }
? if (v-master_idx == -1)
? ? ?errx(1, failed to find \master\ mixer device for volume init);
you should make sure you get outputs.master as opposed to possibly
record.master, or some other master. ?technically speaking, a device
is free to make up whatever class it wants. ?you have to find the
outputs class index, and make sure that master's mixer_class equals
the outputs class index.
D'oh! Thanks for that. This is why (i think) it was failing for Edd
and (possibly) Brynet.
? /* Volume values are stored as 8-bit values, however not all values are
? ?* supported (i.e. fewer than 256 different volume levels may be
? ?* supported). ?As such, to accurately determine the percentages shown
? ?* in the display, we have to find the maximum settings for this
? ?* device.
you could use the delta: devinfo.un.v.delta. ?that is the step size
of the hardware. ?that is, you have to move that many volume units to
affect a change in the hardware. ?you could use this to determine
the largest value ...
Many thanks, this is much easier.
?So, we...
? ?* ? ?1. read the current volume values
? ?* ? ?2. set the volume to the max possible (255)
255 - AUDIO_MAX_GAIN
? ?* ? ?3. read the volume values and see what the max is for this device
? ?* ? ?4. reset the volume to what was read in step 1 so we don't muck
? ?* ? ? ? with the users' volume.
? ?*/
? /* read current volume */
? v-info.dev = v-master_idx;
? v-info.type = AUDIO_MIXER_VALUE;
? if (ioctl(v-dev_fd, AUDIO_MIXER_READ, (v-info)) 0)
? ? ?err(1, ioctl AUDIO_MIXER_READ);
that fails because on many devices because num_channels is not set
correctly. ?in sys/dev/ic/ac97.c:
ac97_mixer_get_port(struct ac86_codec_if *codec_if, mixer_ctrl_t *cp)
{
? ? ? ?struct ac97_softc *as = (struct ac97_softc *)codec_if;
? ? ? ?struct ac97_source_info *si = as-source_info[cp-dev];
...
? ? ? ?case AUDIO_MIXER_VALUE:
? ? ? ?{
? ? ? ? ? ? ? ?const struct audio_mixer_value *value = si-info;
? ? ? ? ? ? ? ?u_int16_t ?l, r;
? ? ? ? ? ? ? ?if ((cp-un.value.num_channels = 0) ||
? ? ? ? ? ? ? ? ? ?(cp-un.value.num_channels value-num_channels))
? ? ? ? ? ? ? ? ? ? ? ?return (EINVAL);
here, value-num_channels == devinfo.un.v.num_channels ...
Hmm, I'm not sure I understand. Let me see if this is what you're
saying (and what i'm getting from ac97.c).
Currently, I ioctl with AUDIO_MIXER_READ, and the mixer_ctrl_t filled
would (I assumed) always have num_channels set to 1 or other (which
I always assume other would be = 2), and I tried to handle like
this...
if (v-info.un.value.num_channels == 1)
v-left = v-right = v-info.un.value.level[AUDIO_MIXER_LEVEL_MONO];
else
{ v-left = v-info.un.value.level[AUDIO_MIXER_LEVEL_LEFT];
v-right = v-info.un.value.level[AUDIO_MIXER_LEVEL_RIGHT];
}
But you're saying (and from the source i can see), that it may return
either 0 channels or ... something greater than values-num_channels,
in which case the ioctl returns EINVAL.
In such a case, what would the appropriate method be for querying
volume level? Or would this represent a situation where this cannot
be queried (lack of hardware or hardware support)?
Or am I lost in left-field here... admittedly I need to look more into this.
for AUDIO_MIXER_READ on a AUDIO_MIXER_VALUE type device, you have to fill
in the number of channels in the mixer_ctrl_t. you can get the number of
channels from AUDIO_MIXER_DEVINFO:
mixer_devinfo_t devinfo;
mixer_ctrl_t ctrl;
devinfo.index = v-master_idx;
ioctl(v-dev_fd, AUDIO_MIXER_DEVINFO, devinfo);
bzero(ctrl);
ctrl.dev = devinfo.index;
ctrl.type = AUDIO_MIXER_VALUE;
ctrl.un.value.num_channels = devinfo.un.v.num_channels;
ioctl(v-dev_fd, AUDIO_MIXER_READ, ctrl);
below are completely untested patches against the tarball. maybe they
will give more hints ;)
--
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
--- stats.h.origMon Aug 31 19:01:31 2009
+++ stats.h Mon Aug 31 18:55:01 2009
@@ -54,6 +54,7 @@ typedef struct volume_info {
mixer_ctrl_t info;
int max;/* max possible value (not always 255) */
+ int nchan;
int left;
int right;
} volume_info_t;
--- stats_collect.c.origMon Aug 31 18:13:00 2009
+++
Re: openports.se
On Tue, Sep 01, 2009 at 02:34:51AM +, Bryan wrote: Is the maintainer of this out for holiday? It's not been updated since 18 Aug. I really like it because I can see the updates at a glance at work, which is not possible via cvs (blocked at work). As a temporary solution, you can use freshbsd.org rss feeds too. Or gmane rss feeds, etc... Landry
