Re: dump LOB status

[Otto Moerbeek]

On Fri, Sep 25, 2020 at 08:42:38AM +0300, Juha Erkkilä wrote:

> 
> > On 24. Sep 2020, at 15.36, Otto Moerbeek  wrote:
> > 
> > On Tue, Sep 22, 2020 at 08:37:22PM +0300, Juha Erkkilä wrote:
> >> Actually, I tested this again and now it appears
> >> dump and restore both work correctly. Previously,
> >> I first tested dump/restore with an empty filesystem,
> >> then with some files, and it may be that the second
> >> time I was accidentally testing restore with the first
> >> dump file.
> >> 
> >> My tests were only with a small amount of files,
> >> I will do a better test with proper data (about
> >> 0.5 terabytes and over 10 files) and will
> >> report again here in a next few days.
> > 
> > Lookin through FreeBSD commits I think you want the main.c one as
> > well, otherwise silent corruption of the dump is still possible.
> > 
> > -Otto
> 
> With that patch I get a message:
> 
> fatal: morestack on g0
>   DUMP: fs is too large for dump!
>   DUMP: The ENTIRE dump is aborted.
> 
> This is on a 2 terabyte filesystem with 0.5 terabytes
> of data “successfully” backed up (or at least I considered
> the backup and restore as successful).

Hmm, I neeed to dig into the dump format and see if the math is right.

-Otto

Re: Primepower 250 vs Sunfire v215

[Theo de Raadt]

Kihaguru Gathura  wrote:

> Do you have experience with the Oracle 3.2TB NVMe PCIE 3.0 Solid State
> Drive with the V215?

Wow, you have a thick wallet.  Use a regular laptop NVME + adapter card
for PCIE and find somewhere else to spend the money.

Re: Primepower 250 vs Sunfire v215

[Kihaguru Gathura]

Hi Claudio,

Based on your experience, which is the go to make for NVME Drive?

Do you have experience with the Oracle 3.2TB NVMe PCIE 3.0 Solid State
Drive with the V215?

Kind regards,

Kihaguru.


On Sunday, September 20, 2020, Claudio Jeker 
wrote:
> On Sun, Sep 20, 2020 at 08:00:45PM +0300, Kihaguru Gathura wrote:
>> > The Primepower is bigger and needs more power but if you find a box
with
>> > good CPUs and memory it should run faster than a V215
>>
>> How did the performance of the PrimePower 250 SCSI drives compare to Sun
>> Fire V215 SAS drives?
>
> Any spinning rust is slow compared to SSD disks. I run my Fire V215 with a
> NVME disk for the busy partitions (but boot from the SAS drives). This is
> not really possible with the primepower 250 (hard to find any kind of SSD
> for that system).
>
> --
> :wq Claudio
>

Re: dump LOB status

[Juha Erkkilä]

> On 22. Sep 2020, at 9.00, Otto Moerbeek  wrote:
> 
> On Mon, Sep 21, 2020 at 10:23:55PM +0300, Juha Erkkilä wrote:
>> 
>> It looks like the same issue has been fixed in
>> FreeBSD: https://svnweb.freebsd.org/base?view=revision&revision=334979 
>> 
>> 
>> The diff applies cleanly to the current OpenBSD source tree.
> 
> Maybe by hand, but not by using patch(1), the context differs a bit.
> 
> Next obvious question: did you test if it fixes your problem? That
> means, do you get a dump that can be restored again?
> 
>   -Otto

Two of my previous mails did not make it to the list
for some reason, but that does not matter.

I tested this with 0.5 terabytes and approximately
70 thousand files, with level 0 and 1 dumps,
doing some additions/deletions/moves between
dumps (no inplace modifications to files, though).
It appears both dump and restore worked
correctly. I did not check all file contents though,
but compared path listings and did contents check
to some randomly sampled files.

I will also test the patch Otto sent to this
list a while ago. This may take some time.

Re: UTF-8 problem with php-7.4

[Stéphane Aulery]

Hello,

Le 24/09/2020 à 19:44, Andrew Hewus Fresh a écrit :

On Thu, Sep 24, 2020 at 11:30:35AM +0200, Boudewijn Dijkstra wrote:

Op Thu, 24 Sep 2020 02:56:51 +0200 schreef Andrew Hewus Fresh
:

On Wed, Sep 23, 2020 at 09:11:44AM +0200, Boudewijn Dijkstra wrote:

Op Thu, 10 Sep 2020 04:01:30 +0200 schreef Bambero :

Hi,

It seems that perl regular expressions lost one polish letter (ą):
https://www.compart.com/en/unicode/U+0105

I can see this problem only under OpenBSD 6.7 with php-7.4 (same >

version of php under linux is OK)


Ex.:

PHP 7.4.10 or 7.4.5


The same happens with any UTF-8 sequence that ends in 0x85.  I guess
(a part of) PHP's PCRE code is not in UTF-8 mode, causing triggers
onCHAR_NEL (=0x85).


I don't know a lot about PHP or the external PCRE library, but my guess
would be that php is treating the string as bytes not characters.  Can
you try using the "u" (PCRE_UTF8) modifier?

https://www.php.net/manual/en/reference.pcre.pattern.modifiers.php


Indeed with "u" the expected 1 is returned! Now the question is, why is this
needed on OpenBSD but not in Linux or Windows?


There are many unicode related changes in php 7.4, so I'm sure they
fixed something.
https://www.php.net/ChangeLog-7.php

I would guess that linux and windows both default to a UTF-8 locale,
while OpenBSD defaults to the C locale.

Does the out put from locale(1) provide you any hints?

Do you get any different results testing it with `LC_ALL=en_US.UTF-8`?

I don't know enough about php to know how it determines what locale to
use, so that may not have any effect, or you may need to adjust
something else.


The default encoding is UTF-8 but preg_* functions() don't follow 
default_charset, input_encoding, output_encoding or internal_encoding 
configs like the multibytes library.


You need to add the u modifier explicitly yourself each time you work 
with an UTF-8 string. No global config flag for that...


And don't relay on mb_detect_encoding() it's utterly broken, unless you 
are sure you are in a case compatible with its limitations.


Regards,

--
Stéphane Aulery

Re: iwm0: fatal firmware error on Dell Latitude E5570

[Uwe Werler]

On 24 Sep 12:24, Jan Stary wrote:
> On Sep 24 11:36:24, h...@stare.cz wrote:
> > This is 6.8-beta/amd64 on a Dell Latitude E5570 (dmesg below).
> > iwm stopped working, saying
> > 
> > iwm0: hw rev 0x200, fw ver 34.0.1, address e4:a4:71:40:21:08
> > iwm0: fatal firmware error
> > iwm0: could not remove MAC context (error 35)
> > iwm0: fatal firmware error
> > iwm0: could not remove MAC context (error 35)
> > iwm0: fatal firmware error
> > iwm0: could not remove MAC context (error 35)
> > [etc]
> > 
> > This is after sysupgrade and a fw_update.
> > Is anyone seeing the same?
> > 
> > Last changes to sys/dev/pci/*iwm* are months ago,
> > and I have seen it work this week ...
> 
> After recompiling current, everything works again. Note that
> it's GENERIC.MP now, as opposed to GENERIC installed by the sysupgrade.
> (Can that be related to a iwm error?)
> 
>   Jan
> 

Hi Jan,

I have a similiar problem when using sysupgrade on Dell 7400 and on one Dell
7280 - installer switches to bsd.sp. I tried to debug that but when I boot
into ramdisk it properly detects MP cpu. Checked that several times. I have
another 7280 with exact the same config (dd'ed the hd) where it doesn't
happen. That's strange.

-- 
wq: ~uw

Re: m4 counting arguments

[Jan Stary]

ping

On Aug 27 11:32:08, h...@stare.cz wrote:
> On Aug 21 21:16:40, h...@stare.cz wrote:
> > On Aug 21 21:04:53, h...@stare.cz wrote:
> > > I came across some m4 problems when trying to compile sox
> > > (a future version of the audio/sox port), which uses the
> > > horrendous autotools to create it's ./configure script.
> > > These tools in turn use m4 to define their macros.
> > > 
> > > What should the following print?
> > > (Please excuse my m4 ignorance.)
> > > 
> > > divert(-1)dnl
> > > changequote([, ])
> > > define([dquote],  [[$@]])
> > > define([argn], [pushdef([_$0], 
> > > [popdef([_$0])]dquote([$]incr([$1])))_$0($@)])
> > 
> > Could it be this?
> > 
> >  The built-ins pushdef and popdef handle macro definitions as a stack.
> >  However, define interacts with the stack in an undefined way.  In this
> >  implementation, define replaces the top-most definition only.  Other
> >  implementations may erase all definitions on the stack instead.
> > 
> > 
> > > define([foo], [argn([10], $@)])
> > > define([bar], [argn([9], shift($@))])
> > > define([baz], [argn([8], shift(shift($@)))])
> > > define([numbers], [[1], [2], [3], [4], [5], [6], [7], [8], [9], [10]])
> > > divert(0)dnl
> > > foo(numbers)
> > > bar(numbers)
> > > baz(numbers)
> > > 
> > > According to upstream, it should be
> > > 
> > > 10
> > > 10
> > > 10
> > > 
> > > On current, it's
> > > 
> > > 101
> > > 90
> > > 10
> 
> No really, should these all be 10,
> or is that undefined because of the stack interaction?
> 
>   Jan
> 
> > > 
> > > https://marc.info/?l=sox-devel&m=159803236823541&w=2
> > > https://sourceforge.net/p/sox/code/ci/affc279d142f843f3f50d4718798303396ee24b4/
> > > 
> > > 
> > 
> > 
> 
> 

Re: sysupgrade after upgrade shuts down VM

[Mischa]

To close the loop on this, this behaviour isn’t present on -current.

Mischa

> On 24 Sep 2020, at 08:30, Mischa  wrote:
> 
> Hi All,
> 
> With the last couple of -current updates I noticed a VM doesn’t come back 
> after running sysupgrade, which it used to do.
> I don’t know exactly when it started but something in the late #60s.
> 
> Running sysupgrade from within the VM, it reboots and goes through the 
> upgrade as normal. Once it’s done with the upgrade it shuts down.
> Tail-end of the process from the latest sysupgrade.
> 
> Set name(s)? (or 'abort' or 'done') [done] done
> Directory does not contain SHA256.sig. Continue without verification? [no] yes
> Installing bsd  100% |**| 20383 KB00:01   
>  
> Installing bsd.rd   100% |**| 10141 KB00:00   
>  
> Installing base68.tgz   100% |**|   289 MB01:42   
>  
> Installing comp68.tgz   100% |**| 74305 KB00:52   
>  
> Installing man68.tgz100% |**|  7484 KB00:10   
>  
> Installing game68.tgz   100% |**|  2739 KB00:01   
>  
> Installing xbase68.tgz  100% |**| 28866 KB00:17   
>  
> Installing xshare68.tgz 100% |**|  4499 KB00:15   
>  
> Installing xfont68.tgz  100% |**| 39342 KB00:23   
>  
> Installing xserv68.tgz  100% |**| 18333 KB00:07   
>  
> Location of sets? (disk http nfs or 'done') [done] done
> Making all device nodes... done.
> Relinking to create unique kernel... done.
> 
> CONGRATULATIONS! Your OpenBSD upgrade has been successfully completed!
> 
> syncing disks... done
> vmmci0: powerdown
> rebooting...
> 
> [EOT]
> 
> # vmctl show tx
>   ID   PID VCPUS  MAXMEM  CURMEM TTYOWNERSTATE NAME
>3 - 14.0G   -   - root  stopped tx
> 
> 
> Anything I can change to have the VM reboot and not shutdown?
> 
> Mischa
> 

Re: UTF-8 problem with php-7.4

[Andrew Hewus Fresh]

On Thu, Sep 24, 2020 at 11:30:35AM +0200, Boudewijn Dijkstra wrote:
> Op Thu, 24 Sep 2020 02:56:51 +0200 schreef Andrew Hewus Fresh
> :
> > On Wed, Sep 23, 2020 at 09:11:44AM +0200, Boudewijn Dijkstra wrote:
> > > Op Thu, 10 Sep 2020 04:01:30 +0200 schreef Bambero :
> > > > Hi,
> > > >
> > > > It seems that perl regular expressions lost one polish letter (ą):
> > > > https://www.compart.com/en/unicode/U+0105
> > > >
> > > > I can see this problem only under OpenBSD 6.7 with php-7.4 (same >
> > > version of php under linux is OK)
> > > >
> > > > Ex.:
> > > >
> > > > PHP 7.4.10 or 7.4.5
> > > >  > > > int(1) // OK
> > > >
> > > > PHP 7.4.10 or 7.4.5
> > > >  > > > int(0) // UPS???
> > > >
> > > > PHP 7.3.21
> > > >  > > > int(1) // OK
> > > >
> > > > PHP 7.3.21
> > > >  > > > int(1) // OK
> > > >
> > > > Any ideas how to fix that?
> > > >
> > > > Regards,
> > > > Bambero
> > > 
> > > The same happens with any UTF-8 sequence that ends in 0x85.  I guess
> > > (a part of) PHP's PCRE code is not in UTF-8 mode, causing triggers
> > > onCHAR_NEL (=0x85).
> > 
> > I don't know a lot about PHP or the external PCRE library, but my guess
> > would be that php is treating the string as bytes not characters.  Can
> > you try using the "u" (PCRE_UTF8) modifier?
> > 
> > https://www.php.net/manual/en/reference.pcre.pattern.modifiers.php
> 
> Indeed with "u" the expected 1 is returned! Now the question is, why is this
> needed on OpenBSD but not in Linux or Windows?

There are many unicode related changes in php 7.4, so I'm sure they
fixed something.
https://www.php.net/ChangeLog-7.php

I would guess that linux and windows both default to a UTF-8 locale,
while OpenBSD defaults to the C locale.

Does the out put from locale(1) provide you any hints?

Do you get any different results testing it with `LC_ALL=en_US.UTF-8`?

I don't know enough about php to know how it determines what locale to
use, so that may not have any effect, or you may need to adjust
something else.

l8rZ,
-- 
andrew - http://afresh1.com

Adding manpower to a late software project makes it later.

Re: ideas needed for password management

[Uwe Werler]

On 24 Sep 10:55, Uwe Werler wrote:
> On 23 Sep 20:52, Hakan E. Duran wrote:
> > Dear all,
> > 
> > I set up a simple mail server on OpenBSD on a VPS, based on OpenSMTP and 
> > Dovecot. The users will be the Unix users on the VPS for simplicity. 
> > However, I now have the problem of allowing users setting and modifying 
> > their own passwords (perhaps even their usernames) without giving them ssh 
> > access to the host. I don't have technical background and training for this 
> > type of work; however, I love doing this, please be gentle with me. The 
> > mail server is a hobby that is intended for family and a few friends, and 
> > is not mission critical.
> > 
> > I thought something like Webmin could work for this purpose, but without 
> > root access of course. However, I am not sure if such a tool exists. Any 
> > other ideas are welcome.
> > 
> > Thank you so much in advance for your suggestions.
> > 
> > Hakan
> > 
> 
> Hi Hakan,
> 
> I had a similiar problem which I solved with Rainloop (as an app in Nextcloud)
> with the POPPASSD plugin and the local poppassd daemon (pkg_add openpoppassd).
> 
> -- 
> wq: ~uw
> 

But as Stuart suggested - I would rather use a db backend for that. I plan
myself to finally use ldapd for that. Most applications allow e.g. password
changes against ldap. In my setup I complicated things more than making it
easier. For example I separated my system user from my "virtual" user for mail
etc. That could have been done in the end simpler with ldap.

-- 
wq: ~uw

Re: ideas needed for password management

[Uwe Werler]

On 23 Sep 20:52, Hakan E. Duran wrote:
> Dear all,
> 
> I set up a simple mail server on OpenBSD on a VPS, based on OpenSMTP and 
> Dovecot. The users will be the Unix users on the VPS for simplicity. However, 
> I now have the problem of allowing users setting and modifying their own 
> passwords (perhaps even their usernames) without giving them ssh access to 
> the host. I don't have technical background and training for this type of 
> work; however, I love doing this, please be gentle with me. The mail server 
> is a hobby that is intended for family and a few friends, and is not mission 
> critical.
> 
> I thought something like Webmin could work for this purpose, but without root 
> access of course. However, I am not sure if such a tool exists. Any other 
> ideas are welcome.
> 
> Thank you so much in advance for your suggestions.
> 
> Hakan
> 

Hi Hakan,

I had a similiar problem which I solved with Rainloop (as an app in Nextcloud)
with the POPPASSD plugin and the local poppassd daemon (pkg_add openpoppassd).

-- 
wq: ~uw

Re: iwm0: fatal firmware error on Dell Latitude E5570

[Theo de Raadt]

Uwe Werler  wrote:

> On 24 Sep 12:24, Jan Stary wrote:
> > On Sep 24 11:36:24, h...@stare.cz wrote:
> > > This is 6.8-beta/amd64 on a Dell Latitude E5570 (dmesg below).
> > > iwm stopped working, saying
> > > 
> > >   iwm0: hw rev 0x200, fw ver 34.0.1, address e4:a4:71:40:21:08
> > >   iwm0: fatal firmware error
> > >   iwm0: could not remove MAC context (error 35)
> > >   iwm0: fatal firmware error
> > >   iwm0: could not remove MAC context (error 35)
> > >   iwm0: fatal firmware error
> > >   iwm0: could not remove MAC context (error 35)
> > >   [etc]
> > > 
> > > This is after sysupgrade and a fw_update.
> > > Is anyone seeing the same?
> > > 
> > > Last changes to sys/dev/pci/*iwm* are months ago,
> > > and I have seen it work this week ...
> > 
> > After recompiling current, everything works again. Note that
> > it's GENERIC.MP now, as opposed to GENERIC installed by the sysupgrade.
> > (Can that be related to a iwm error?)
> > 
> > Jan
> > 
> 
> Hi Jan,
> 
> I have a similiar problem when using sysupgrade on Dell 7400 and on one Dell
> 7280 - installer switches to bsd.sp. I tried to debug that but when I boot
> into ramdisk it properly detects MP cpu. Checked that several times. I have
> another 7280 with exact the same config (dd'ed the hd) where it doesn't
> happen. That's strange.

I think kernel random relinking and other address space randomization is
exposing either an uninitialized variable or alignment attribute the
chip wants but the driver doesn't satisfy.

Re: ideas needed for password management

[Torsten]

Hi
You need a smtpd server which is native to BSD and supports auth backends

Have a look here
https://www.fehcom.de/sqmail/sqmail.html

I use it with dovecot with mysql auth backend, sqlmail basically calls a
dovadmin socket to authenticate, so no need for mysql as long as you can
login to dovecot pop3 or imap

T

-Original Message-
From: owner-m...@openbsd.org  On Behalf Of Roderick
Sent: 24 September 2020 14:33
To: Hakan E. Duran 
Cc: misc@openbsd.org
Subject: Re: ideas needed for password management


(1) I would separate login to Email (smtp+imap authentication)
 from any other login (to machine) as many people told you here.

(2) Perhaps write a cgi script? But that needs a lot of care
 due to security.

(3) offer a web mailer that has this service? Prayer webmail has
 this, but it looks very primitive, just calls a program as I
 remember, and seems not to be mantained. Perhaps other webmail has it?

Rod.



On Wed, 23 Sep 2020, Hakan E. Duran wrote:

> Dear all,
>
> I set up a simple mail server on OpenBSD on a VPS, based on OpenSMTP and
Dovecot. The users will be the Unix users on the VPS for simplicity.
However, I now have the problem of allowing users setting and modifying
their own passwords (perhaps even their usernames) without giving them ssh
access to the host. I don't have technical background and training for this
type of work; however, I love doing this, please be gentle with me. The mail
server is a hobby that is intended for family and a few friends, and is not
mission critical.
>
> I thought something like Webmin could work for this purpose, but without
root access of course. However, I am not sure if such a tool exists. Any
other ideas are welcome.
>
> Thank you so much in advance for your suggestions.
>
> Hakan
>
>

Re: iwm0: fatal firmware error on Dell Latitude E5570

[Christian Weisgerber]

On 2020-09-24, Jan Stary  wrote:

> This is 6.8-beta/amd64 on a Dell Latitude E5570 (dmesg below).
> iwm stopped working, saying
>
>   iwm0: hw rev 0x200, fw ver 34.0.1, address e4:a4:71:40:21:08
>   iwm0: fatal firmware error
>   iwm0: could not remove MAC context (error 35)

I've been getting a lot of those lately, but my iwm keeps recovering
from them eventually.

Frankly, I've mostly stopped paying attention.  I update my laptop
every other week or so, and the reliability of wi-fi keeps fluctuating
from kernel to kernel, sometimes it's better, sometimes it's worse,
and I don't think it correlates well with commits or firmware
updates.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: ideas needed for password management

[ben]

I may have misunderstoor OPs problem.


Ben Raskin.

Re: UTF-8 problem with php-7.4

[Boudewijn Dijkstra]

Op Thu, 24 Sep 2020 02:56:51 +0200 schreef Andrew Hewus Fresh  
:

On Wed, Sep 23, 2020 at 09:11:44AM +0200, Boudewijn Dijkstra wrote:

Op Thu, 10 Sep 2020 04:01:30 +0200 schreef Bambero :
> Hi,
>
> It seems that perl regular expressions lost one polish letter (ą):
> https://www.compart.com/en/unicode/U+0105
>
> I can see this problem only under OpenBSD 6.7 with php-7.4 (same >  
version of php under linux is OK)

>
> Ex.:
>
> PHP 7.4.10 or 7.4.5
>  int(1) // OK
>
> PHP 7.4.10 or 7.4.5
>  int(0) // UPS???
>
> PHP 7.3.21
>  int(1) // OK
>
> PHP 7.3.21
>  int(1) // OK
>
> Any ideas how to fix that?
>
> Regards,
> Bambero

The same happens with any UTF-8 sequence that ends in 0x85.  I guess (a  
part of) PHP's PCRE code is not in UTF-8 mode, causing triggers on 
CHAR_NEL (=0x85).


I don't know a lot about PHP or the external PCRE library, but my guess
would be that php is treating the string as bytes not characters.  Can
you try using the "u" (PCRE_UTF8) modifier?

https://www.php.net/manual/en/reference.pcre.pattern.modifiers.php


Indeed with "u" the expected 1 is returned! Now the question is, why is  
this needed on OpenBSD but not in Linux or Windows?





--
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/

Re: ideas needed for password management

[Roderick]

(1) I would separate login to Email (smtp+imap authentication)
from any other login (to machine) as many people told you here.

(2) Perhaps write a cgi script? But that needs a lot of care
due to security.

(3) offer a web mailer that has this service? Prayer webmail has
this, but it looks very primitive, just calls a program as I
remember, and seems not to be mantained. Perhaps other webmail has it?

Rod.



On Wed, 23 Sep 2020, Hakan E. Duran wrote:


Dear all,

I set up a simple mail server on OpenBSD on a VPS, based on OpenSMTP and 
Dovecot. The users will be the Unix users on the VPS for simplicity. However, I 
now have the problem of allowing users setting and modifying their own 
passwords (perhaps even their usernames) without giving them ssh access to the 
host. I don't have technical background and training for this type of work; 
however, I love doing this, please be gentle with me. The mail server is a 
hobby that is intended for family and a few friends, and is not mission 
critical.

I thought something like Webmin could work for this purpose, but without root 
access of course. However, I am not sure if such a tool exists. Any other ideas 
are welcome.

Thank you so much in advance for your suggestions.

Hakan

Re: ideas needed for password management

[Daniel Jakots]

On Thu, 24 Sep 2020 09:29:37 -0400 (EDT), ben  wrote:

> You don't. Pass is a password manager. It stores passwords for later
> use.

Indeed. So how is pass relevant to OP's problem?

Re: ideas needed for password management

[ben]

You don't. Pass is a password manager. It stores passwords for later use.


Ben Raskin.

MJPEG in video(1)

[Jan Stary]

Hello Laurie,

On Sep 21 17:54:40, lau...@tratt.net wrote:
> However, there's a probably deeper point here. IMHO, video(1) isn't really a
> sensible tool for viewing or recording video

I find it nice that a base tool exists
for viewing and recording video, even
if not the compressed formats.

> as it can't access a camera's
> MJPEG mode (assuming the camera has one!) without ld tricks.

Can you elaborate please? I was under the impression that
video(1) can only do the video -e encodings, namely:

Valid arguments are ‘uyvy’, ‘yuy2’ and ‘yv12’.  The default
is ‘yuy2’ unless file is being used and only supports ‘uyvy’,
in which case ‘uyvy’ will be used by default.

What "ld tricks" would make video(1) recognize the mjpeg modes?

> In general, I suggest that people use ffplay/ffmpeg

Indeed, ffplay -f v4l2 -list_formats all -i /dev/video0
reveals MJPEG support in most webcams here. I have one that
only does mjpeg, so ffmpeg is currently the only way to use it.

> [1] https://marc.info/?l=openbsd-tech&m=160053691513681&w=2

Thanks!

Jan

Re: ideas needed for password management

[Daniel Jakots]

On Thu, 24 Sep 2020 08:56:01 -0400 (EDT), ben  wrote:

> The pass program for most UNIX based operating systems
> should be available. I'm pretty sure on OpenBSD it's 
> under a different name, so query for package names
> with 'pass' in them.


Out of curiosity, how do you interface OpenSMTPD/Dovecot with pass?

mention sox in multimedia faq

[Jan Stary]

It breaks my heart to see audacity mentioned but not SoX.

Jan

--- faq13.html.orig Thu Sep 24 15:04:53 2020
+++ faq13.html  Thu Sep 24 15:04:36 2020
@@ -242,8 +242,8 @@ is unmuted.
 
 If needed, the resulting WAV file could be compressed with the
 appropriate program from the ports tree.
-Alternatively, ports like audacity or ffmpeg can be used to record, process
-and compress audio files.
+Alternatively, ports like sox or ffmpeg or audacity can be used
+to record, process and compress audio files.
 
 Recording a Monitor Mix of All Audio Playback
 

Re: ideas needed for password management

[ben]

The pass program for most UNIX based operating systems
should be available. I'm pretty sure on OpenBSD it's 
under a different name, so query for package names
with 'pass' in them.


Ben Raskin.

Re: dump LOB status

[Otto Moerbeek]

On Tue, Sep 22, 2020 at 08:37:22PM +0300, Juha Erkkilä wrote:

> 
> > On 22. Sep 2020, at 15.04, Juha Erkkilä  wrote:
> > 
> >> On 22. Sep 2020, at 9.00, Otto Moerbeek  wrote:
> >> Maybe by hand, but not by using patch(1), the context differs a bit.
> >> 
> >> Next obvious question: did you test if it fixes your problem? That
> >> means, do you get a dump that can be restored again?
> >> 
> >>-Otto
> > 
> > Thanks Otto for a very good question!  So no,
> > do not use that patch as is, it breaks restore
> > as it can not be used to restore any files.
> 
> Actually, I tested this again and now it appears
> dump and restore both work correctly. Previously,
> I first tested dump/restore with an empty filesystem,
> then with some files, and it may be that the second
> time I was accidentally testing restore with the first
> dump file.
> 
> My tests were only with a small amount of files,
> I will do a better test with proper data (about
> 0.5 terabytes and over 10 files) and will
> report again here in a next few days.

Lookin through FreeBSD commits I think you want the main.c one as
well, otherwise silent corruption of the dump is still possible.

-Otto

Index: main.c
===
RCS file: /cvs/src/sbin/dump/main.c,v
retrieving revision 1.61
diff -u -p -r1.61 main.c
--- main.c  28 Jun 2019 13:32:43 -  1.61
+++ main.c  24 Sep 2020 10:24:45 -
@@ -92,7 +92,7 @@ main(int argc, char *argv[])
int ch, mode;
struct tm then;
struct statfs fsbuf;
-   int i, anydirskipped, bflag = 0, Tflag = 0, honorlevel = 1;
+   int i, anydirskipped, c_count, bflag = 0, Tflag = 0, honorlevel = 1;
ino_t maxino;
time_t t;
int dirlist;
@@ -442,6 +442,9 @@ main(int argc, char *argv[])
 #endif
maxino = (ino_t)sblock->fs_ipg * sblock->fs_ncg;
mapsize = roundup(howmany(maxino, NBBY), TP_BSIZE);
+   c_count = howmany(mapsize * sizeof(char), TP_BSIZE);
+   if (c_count > TP_NINDIR)
+   quit("fs is too large for dump!");
usedinomap = calloc((unsigned) mapsize, sizeof(char));
dumpdirmap = calloc((unsigned) mapsize, sizeof(char));
dumpinomap = calloc((unsigned) mapsize, sizeof(char));
Index: tape.c
===
RCS file: /cvs/src/sbin/dump/tape.c,v
retrieving revision 1.45
diff -u -p -r1.45 tape.c
--- tape.c  28 Jun 2019 13:32:43 -  1.45
+++ tape.c  24 Sep 2020 10:24:45 -
@@ -330,7 +330,8 @@ flushtape(void)
}
 
blks = 0;
-   if (spcl.c_type != TS_END) {
+   if (spcl.c_type != TS_END && spcl.c_type != TS_CLRI &&
+   spcl.c_type != TS_BITS) {
for (i = 0; i < spcl.c_count; i++)
if (spcl.c_addr[i] != 0)
blks++;

Re: iwm0: fatal firmware error on Dell Latitude E5570

[Jan Stary]

On Sep 24 11:36:24, h...@stare.cz wrote:
> This is 6.8-beta/amd64 on a Dell Latitude E5570 (dmesg below).
> iwm stopped working, saying
> 
>   iwm0: hw rev 0x200, fw ver 34.0.1, address e4:a4:71:40:21:08
>   iwm0: fatal firmware error
>   iwm0: could not remove MAC context (error 35)
>   iwm0: fatal firmware error
>   iwm0: could not remove MAC context (error 35)
>   iwm0: fatal firmware error
>   iwm0: could not remove MAC context (error 35)
>   [etc]
> 
> This is after sysupgrade and a fw_update.
> Is anyone seeing the same?
> 
> Last changes to sys/dev/pci/*iwm* are months ago,
> and I have seen it work this week ...

After recompiling current, everything works again. Note that
it's GENERIC.MP now, as opposed to GENERIC installed by the sysupgrade.
(Can that be related to a iwm error?)

Jan

OpenBSD 6.8-beta (GENERIC.MP) #0: Thu Sep 24 12:15:13 CEST 2020
h...@dell.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16810315776 (16031MB)
avail mem = 16285798400 (15531MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xeac10 (107 entries)
bios0: vendor Dell Inc. version "1.5.0" date 04/22/2016
bios0: Dell Inc. Latitude E5570
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT LPIT SSDT SSDT SSDT DBGP 
DBG2 SSDT UEFI SSDT SSDT SLIC ASF!
acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) 
RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) 
RP13(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-6440HQ CPU @ 2.60GHz, 2295.26 MHz, 06-5e-03
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-6440HQ CPU @ 2.60GHz, 2294.66 MHz, 06-5e-03
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i5-6440HQ CPU @ 2.60GHz, 2294.66 MHz, 06-5e-03
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i5-6440HQ CPU @ 2.60GHz, 2294.66 MHz, 06-5e-03
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf000, bus 0-127
acpihpet0 at acpi0: 2399 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG0)
acpiprt2 at acpi0: bus -1 (PEG1)
acpiprt3 at acpi0: bus -1 (PEG2)
acpiprt4

Re: ideas needed for password management

[Stuart Henderson]

On 2020-09-24, Hakan E. Duran  wrote:
> I set up a simple mail server on OpenBSD on a VPS, based on OpenSMTP
> and Dovecot. The users will be the Unix users on the VPS for simplicity.
> However, I now have the problem of allowing users setting and modifying
> their own passwords (perhaps even their usernames) without giving them
> ssh access to the host. I don't have technical background and training
> for this type of work; however, I love doing this, please be gentle with
> me. The mail server is a hobby that is intended for family and a few
> friends, and is not mission critical.

The email daemons don't have to use the passwords associated with Unix
accounts, they can do their own authentication against some database
(LDAP/SQL). With this it will be a lot easier to allow self-service
password changes via a web-based system as you're just updating a
database record.

FWIW on dedicated mailservers I find it simpler to skip the separate
Unix user accounts completely and just use a single uid for mail storage,
especially if using shared mailboxes. It's not difficult to setup -
https://wiki.dovecot.org/VirtualUsers

iwm0: fatal firmware error on Dell Latitude E5570

[Jan Stary]

This is 6.8-beta/amd64 on a Dell Latitude E5570 (dmesg below).
iwm stopped working, saying

iwm0: hw rev 0x200, fw ver 34.0.1, address e4:a4:71:40:21:08
iwm0: fatal firmware error
iwm0: could not remove MAC context (error 35)
iwm0: fatal firmware error
iwm0: could not remove MAC context (error 35)
iwm0: fatal firmware error
iwm0: could not remove MAC context (error 35)
[etc]

This is after sysupgrade and a fw_update.
Is anyone seeing the same?

Last changes to sys/dev/pci/*iwm* are months ago,
and I have seen it work this week ...

Jan



OpenBSD 6.8-beta (GENERIC) #76: Wed Sep 23 15:23:23 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 16810315776 (16031MB)
avail mem = 16285892608 (15531MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xeac10 (107 entries)
bios0: vendor Dell Inc. version "1.5.0" date 04/22/2016
bios0: Dell Inc. Latitude E5570
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT LPIT SSDT SSDT SSDT DBGP 
DBG2 SSDT UEFI SSDT SSDT SLIC ASF!
acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) 
RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) 
RP13(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-6440HQ CPU @ 2.60GHz, 2295.52 MHz, 06-5e-03
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf000, bus 0-127
acpihpet0 at acpi0: 2399 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG0)
acpiprt2 at acpi0: bus -1 (PEG1)
acpiprt3 at acpi0: bus -1 (PEG2)
acpiprt4 at acpi0: bus -1 (RP09)
acpiprt5 at acpi0: bus -1 (RP10)
acpiprt6 at acpi0: bus -1 (RP11)
acpiprt7 at acpi0: bus -1 (RP12)
acpiprt8 at acpi0: bus -1 (RP13)
acpiprt9 at acpi0: bus -1 (RP01)
acpiprt10 at acpi0: bus 1 (RP02)
acpiprt11 at acpi0: bus 2 (RP03)
acpiprt12 at acpi0: bus -1 (RP04)
acpiprt13 at acpi0: bus -1 (RP05)
acpiprt14 at acpi0: bus -1 (RP06)
acpiprt15 at acpi0: bus -1 (RP07)
acpiprt16 at acpi0: bus -1 (RP08)
acpiprt17 at acpi0: bus -1 (RP17)
acpiprt18 at acpi0: bus -1 (RP18)
acpiprt19 at acpi0: bus -1 (RP19)
acpiprt20 at acpi0: bus -1 (RP20)
acpiprt21 at acpi0: bus -1 (RP14)
acpiprt22 at acpi0: bus -1 (RP15)
acpiprt23 at acpi0: bus -1 (RP16)
acpiec0 at acpi0
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
extent `acpipci0 pcibus' (0x0 - 0xff), flags=0
 0x7f - 0xff
extent `acpipci0 pciio' (0x0 - 0x), flags=0
 0xcf8 - 0xcff
 0x1 - 0x
extent `acpipci0 pcimem' (0x0 - 0x), flags=0
 0x0 - 0x9
 0xc - 0xafff
 0xf000 - 0xfcff
 0xfe80 - 0x
acpicmos0 at acpi0
"INT3403" at acpi0 not configured
"INT3403" at acpi0 not configured
"SMO8810" at acpi0 not configured
"INT3403" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"INT33A1" at acpi0 not configured
"PNP0C14" at acpi0 not configured
acpibtn0 at acpi0: LID0
acpibtn1 at acpi0: PBTN
acpibtn2 at acpi0: SBTN
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT0 model "DELL 7V69Y53" serial 2106 type LiP oem "SMP"
"DELLABC6" at acpi0 not configured
"DELLABCE" at acpi0 not configured
"INT3400" at acpi0 not configured
acpicpu0 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: PG00, resource for PEG0
acpipwrres1 at acpi0: PG01, resource for PEG1
acpipwrres2 at acpi0: PG02, resource for PEG2
acpipwrres3 at acpi0: WRST
acpipwrres4 at acpi0: WRST
acpipwrres5 at acpi0: WRST
acpipwrres6 at acpi0: WRST
acpipwrres7 at acpi0: WRST
acpipwrres8 at acpi0: WRST
acpipwrres9 at acpi0: WRST
acpipwrres10 at acpi0: WRST
acpipwrres11 at acpi0: WRST
acpipwrres12 at acpi0: WRST
acpipwrres13 at acpi0: WRST
acpipwrres14 at acpi0: WRST
acpipwrres15 at acpi0: WRST
acpipwrres16 at acpi0: WRST
acpipwrres17 at acpi0: 

Re: webcam fixes and changes in -current

[Jan Stary]

> On Sep 23 20:55:45, h...@stare.cz wrote:
> > On Aug 29 18:06:32, lau...@tratt.net wrote:
> > > Lots of us have to use webcams more than we used to. There have been some
> > > recent changes in OpenBSD support for webcams that some might find useful.
> > > Most of the hard work was done by Marcus Glocker, with input from Ingo
> > > Feinerer, sc.dying, and myself.
> > 
> > Thanks to all! The uvideo on my old MacBook1,1
> > (dmesg below) is back, for instance.
> 
> Ah. This is with a diff (below) I got on misc earlier.
> Sorry for the confusion.

Here is the same with UVIDEO_DEBUG, if it's of any help.
I can donate the MacBook if anyone is interested.

Jan


$ video -q
video device /dev/video:
  encodings: uyvy
  frame sizes (width x height, in pixels) and rates (in frames per second):
320x240: 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 
30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30
352x288: 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 
30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30
640x480: 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 
30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30
  controls: brightness, saturation, gamma, sharpness

messages:

Sep 24 09:58:29 mb32 /bsd: uvideo0: uvideo_open: sc=0xd580b000
Sep 24 09:58:29 mb32 /bsd: uvideo0: uvideo_find_ctrl: control not supported by 
device!
Sep 24 09:58:29 mb32 last message repeated 4 times
Sep 24 09:58:30 mb32 /bsd: uvideo0: uvideo_close: sc=0xd580b000
Sep 24 09:58:30 mb32 /bsd: uvideo0: uvideo_vs_free_isoc


$ video -c
video: VIDIOC_G_CTRL: Invalid argument
brightness=63
saturation=5
gamma=100
sharpness=3

messages:

Sep 24 09:58:35 mb32 /bsd: uvideo0: uvideo_open: sc=0xd580b000
Sep 24 09:58:35 mb32 /bsd: uvideo0: uvideo_find_ctrl: control not supported by 
device!
Sep 24 09:58:35 mb32 last message repeated 4 times
Sep 24 09:58:35 mb32 /bsd: uvideo0: uvideo_s_fmt: requested width=640, 
height=480
Sep 24 09:58:35 mb32 /bsd: uvideo0: uvideo_find_res: frame index 0: width=640, 
height=480
Sep 24 09:58:35 mb32 /bsd: uvideo0: uvideo_find_res: frame index 1: width=352, 
height=288
Sep 24 09:58:35 mb32 /bsd: uvideo0: uvideo_find_res: frame index 2: width=320, 
height=240
Sep 24 09:58:35 mb32 /bsd: uvideo0: SET probe request successfully
Sep 24 09:58:35 mb32 /bsd: bmHint=0x01
Sep 24 09:58:35 mb32 /bsd: bFormatIndex=0x01
Sep 24 09:58:35 mb32 /bsd: bFrameIndex=0x01
Sep 24 09:58:35 mb32 /bsd: dwFrameInterval=33 (100ns units)
Sep 24 09:58:35 mb32 /bsd: wKeyFrameRate=0
Sep 24 09:58:35 mb32 /bsd: wPFrameRate=0
Sep 24 09:58:35 mb32 /bsd: wCompQuality=0
Sep 24 09:58:35 mb32 /bsd: wCompWindowSize=0
Sep 24 09:58:35 mb32 /bsd: wDelay=0 (ms)
Sep 24 09:58:35 mb32 /bsd: dwMaxVideoFrameSize=0 (bytes)
Sep 24 09:58:35 mb32 /bsd: dwMaxPayloadTransferSize=0 (bytes)
Sep 24 09:58:35 mb32 /bsd: uvideo0: GET probe request successfully
Sep 24 09:58:35 mb32 /bsd: bmHint=0x00
Sep 24 09:58:35 mb32 /bsd: bFormatIndex=0x01
Sep 24 09:58:35 mb32 /bsd: bFrameIndex=0x01
Sep 24 09:58:35 mb32 /bsd: dwFrameInterval=33 (100ns units)
Sep 24 09:58:35 mb32 /bsd: wKeyFrameRate=0
Sep 24 09:58:35 mb32 /bsd: wPFrameRate=0
Sep 24 09:58:35 mb32 /bsd: wCompQuality=0
Sep 24 09:58:35 mb32 /bsd: wCompWindowSize=0
Sep 24 09:58:35 mb32 /bsd: wDelay=33 (ms)
Sep 24 09:58:35 mb32 /bsd: dwMaxVideoFrameSize=614400 (bytes)
Sep 24 09:58:35 mb32 /bsd: dwMaxPayloadTransferSize=3072 (bytes)
Sep 24 09:58:35 mb32 /bsd: fixed dwMaxVideoFrameSize=614400, width=640 
height=480 bpp=16
Sep 24 09:58:35 mb32 /bsd: uvideo0: SET commit request successfully
Sep 24 09:58:35 mb32 /bsd: uvideo0: uvideo_s_fmt: offered width=640, height=480
Sep 24 09:58:35 mb32 /bsd: uvideo0: SET probe request successfully
Sep 24 09:58:35 mb32 /bsd: bmHint=0x01
Sep 24 09:58:35 mb32 /bsd: bFormatIndex=0x01
Sep 24 09:58:35 mb32 /bsd: bFrameIndex=0x01
Sep 24 09:58:35 mb32 /bsd: dwFrameInterval=33 (100ns units)
Sep 24 09:58:35 mb32 /bsd: wKeyFrameRate=0
Sep 24 09:58:35 mb32 /bsd: wPFrameRate=0
Sep 24 09:58:35 mb32 /bsd: wCompQuality=0
Sep 24 09:58:35 mb32 /bsd: wCompWindowSize=0
Sep 24 09:58:35 mb32 /bsd: wDelay=0 (ms)
Sep 24 09:58:35 mb32 /bsd: dwMaxVideoFrameSize=0 (bytes)
Sep 24 09:58:35 mb32 /bsd: dwMaxPayloadTransferSize=0 (bytes)
Sep 24 09:58:35 mb32 /bsd: uvideo0: GET probe request successfully
Sep 24 09:58:35 mb32 /bsd: bmHint=0x00
Sep 24 09:58:35 mb32 /bsd: bFormatIndex=0x01
Sep 24 09:58:35 mb32 /bsd: bFrameIndex=0x01
Sep 24 09:58:35 mb32 /bsd: dwFrameInterval=33 (100ns units)
Sep 24 09:58:35 mb32 /bsd: wKeyFrameRate=0
Sep 24 09:58:35 mb32 /bsd: wPFrameRate=0
Sep 24 09:58:35 mb32 /bsd: wCompQuality=0
Sep 24 09:58:35 mb32 /bsd: wCompWindowSize=0
Sep 24 09:58:35 mb32 /bsd: wDelay=33 (ms)
Sep 24 09:58:35 mb32 /bsd: dwMaxVideoFrameSize=614400 (bytes)
Sep 24 09:58:35 mb32 /bsd: dwMaxPayloadTransferSize=3072 (bytes)
Sep 24 09:58:35 mb32 /bsd: fixed dwMaxVideoFrameSize=614400, width=640 
height=480 bpp

Re: webcam fixes and changes in -current

[Jan Stary]

On Aug 29 18:06:32, lau...@tratt.net wrote:
> The first change is that MJPEG in cameras now works reliably. In essence,
> most webcams can deliver uncompressed video at a low frame rate or
> compressed (MJPEG) at a high frame rate.

Testing with a MikrOkular HD by Bresser,
a USB camera that plugs into a microscope tubus.

> ffplay -f v4l2 -list_formats all -i /dev/video0

Compressed: mjpeg : MJPEG : 1280x720 640x480

There is no "Raw" stanza - it only emits a MJPEG stream.

>   $ video -q

video: /dev/video has no usable YUV encodings.

This seems to agree with ffmpeg's detection.

> As that suggests, video(1) only easily supports YUY2/YUYV422.

I am unsure about "easily" - is video(1)
expected to support MJPEG at all?

> The easiest
> way to see higher frame rates I know of is to use ffmpeg. Most cameras can
> sustain 30fps (or sometimes 60fps) at high resolutions as can be seen with:
> 
>   $ ffplay -f v4l2 -input_format mjpeg -video_size 1920x1080 -i /dev/video0

Works like a charm.

> If you use video chat in a browser, you should find that it can now reliably
> support higher resolutions without problems.

I can't wait to stream yeast replication live, now that I can :-)

> however, the settings are "sticky" so they effect
> subsequent programs which use the webcam.

Yes: ffplay -f v4l2 -input_format mjpeg -video_size 1280x720 -i /dev/video0
will make the next ffplay -f v4l2 -input_format mjpeg -i /dev/video0
also use 1280x720; same for 640x480.

> Overall, I think this makes webcams much more usable under OpenBSD

It's an obscure networking OS, everybody knows that.

Thanks to all,

Jan


Sep 24 09:02:12 mb32 /bsd: uvideo1 at uhub0 port 1 configuration 1 interface 0 
"Alcor Micro MikrOkularHD" rev 2.00/0.00 addr 3
Sep 24 09:02:12 mb32 /bsd: bLength=9
Sep 24 09:02:12 mb32 /bsd: bDescriptorType=0x02 (UDESC_CONFIG)
Sep 24 09:02:12 mb32 /bsd: |
Sep 24 09:02:12 mb32 /bsd: bLength=9
Sep 24 09:02:12 mb32 /bsd: bDescriptorType=0x02
Sep 24 09:02:12 mb32 /bsd: wTotalLength=311
Sep 24 09:02:12 mb32 /bsd: bNumInterface=0x02
Sep 24 09:02:12 mb32 /bsd: bConfigurationValue=0x01
Sep 24 09:02:12 mb32 /bsd: iConfiguration=0x00
Sep 24 09:02:12 mb32 /bsd: bmAttributes=0x80
Sep 24 09:02:12 mb32 /bsd: bMaxPower=0x64
Sep 24 09:02:12 mb32 /bsd: bMaxPower=0x64
Sep 24 09:02:12 mb32 /bsd: bLength=8
Sep 24 09:02:12 mb32 /bsd: bDescriptorType=0x0b (UDESC_IFACE_ASSOC)
Sep 24 09:02:12 mb32 /bsd: |
Sep 24 09:02:12 mb32 /bsd: bLength=8
Sep 24 09:02:12 mb32 /bsd: bDescriptorType=0x0b
Sep 24 09:02:12 mb32 /bsd: bFirstInterface=0x00
Sep 24 09:02:12 mb32 /bsd: bInterfaceCount=2
Sep 24 09:02:12 mb32 /bsd: bFunctionClass=0x0e
Sep 24 09:02:12 mb32 /bsd: bFunctionSubClass=0x03
Sep 24 09:02:12 mb32 /bsd: bFunctionProtocol=0x00
Sep 24 09:02:12 mb32 /bsd: iFunction=0x04
Sep 24 09:02:12 mb32 /bsd: iFunction=0x04
Sep 24 09:02:12 mb32 /bsd: bLength=9
Sep 24 09:02:12 mb32 /bsd: bDescriptorType=0x04 (UDESC_INTERFACE)
Sep 24 09:02:12 mb32 /bsd: |
Sep 24 09:02:12 mb32 /bsd: bLength=9
Sep 24 09:02:12 mb32 /bsd: bDescriptorType=0x04
Sep 24 09:02:12 mb32 /bsd: bInterfaceNumber=0x00
Sep 24 09:02:12 mb32 /bsd: bAlternateSetting=0x00
Sep 24 09:02:12 mb32 /bsd: bNumEndpoints=1
Sep 24 09:02:12 mb32 /bsd: bInterfaceClass=0x0e
Sep 24 09:02:12 mb32 /bsd: bInterfaceSubClass=0x01
Sep 24 09:02:12 mb32 /bsd: bInterfaceProtocol=0x00
Sep 24 09:02:12 mb32 /bsd: iInterface=0x04
Sep 24 09:02:12 mb32 /bsd: iInterface=0x04
Sep 24 09:02:12 mb32 /bsd: bLength=13
Sep 24 09:02:12 mb32 /bsd: bDescriptorType=0x24 (CS_INTERFACE)
Sep 24 09:02:12 mb32 /bsd: bDescriptorSubtype=0x01 (UDESCSUB_VC_HEADER)
Sep 24 09:02:12 mb32 /bsd: |
Sep 24 09:02:12 mb32 /bsd: bLength=13
Sep 24 09:02:12 mb32 /bsd: bDescriptorType=0x24
Sep 24 09:02:12 mb32 /bsd: bDescriptorSubtype=0x01
Sep 24 09:02:12 mb32 /bsd: bcdUVC=0x0100
Sep 24 09:02:12 mb32 /bsd: wTotalLength=79
Sep 24 09:02:12 mb32 /bsd: dwClockFrequency=3000
Sep 24 09:02:12 mb32 /bsd: bInCollection=0x01
Sep 24 09:02:12 mb32 /bsd: bInCollection=0x01
Sep 24 09:02:12 mb32 /bsd: bLength=28
Sep 24 09:02:12 mb32 /bsd: bDescriptorType=0x24 (CS_INTERFACE)
Sep 24 09:02:12 mb32 /bsd: bDescriptorSubtype=0x06 (UDESCSUB_VC_EXTENSION_UNIT)
Sep 24 09:02:12 mb32 /bsd: |
Sep 24 09:02:12 mb32 /bsd: bLength=28
Sep 24 09:02:12 mb32 /bsd: bDescriptorType=0x24
Sep 24 09:02:12 mb32 /bsd: bDescriptorSubtype=0x06
Sep 24 09:02:12 mb32 /bsd: bUnitID=0x06
Sep 24 09:02:12 mb32 /bsd: guidExtensionCode=0xb0d0bb68a461834b90b7a6215f3c4f70
Sep 24 09:02:12 mb32 /bsd: bNumControls=0x18
Sep 24 09:02:12 mb32 /bsd: bNrInPins=0x01
Sep 24 09:02:12 mb32 /bsd: bNrInPins=0x01
Sep 24 09:02:12 mb32 /bsd: bLength=18
Sep 24 09:02:12 mb32 /bsd: bDescriptorType=0x24 (CS_INTERFACE)
Sep 24 09:02:12 mb32 /bsd: bDescriptorSubtype=0x02 (UDESCSUB_VC_INPUT_TERMINAL)
Sep 24 09:02:12 mb32 /bsd: |
Sep 24 09:02:12 mb32 /bsd: bLength=18
Sep 24 09:02:12 mb32 /bsd: bDescriptorType=0x24
Sep 24 09:02:12 mb32 /bsd: bDescriptorSubtype=0x02
Sep 24 09:02:12 mb32 /bsd: b