Re: pkg_add errors on current
On Sun 17 Feb 2019 12:25 PM, Stuart Henderson wrote: > On 2019-02-16, Jungle Boogie wrote: > > Hi All, > > > > Running openBSD snapshot on amd64 from today, but I think this has been an > > issue since > > perl 5.28 was added. > > Where did .../perl5/site_perl/amd64-openbsd/auto/List/Util/Util.so come from? > It isn't in ports. > > However you installed it, you either need to rebuild it or remove it. Thanks for the hint! After removing, pkg_add works as normal. > >
patch for Inseego/Novatel MiFi 8800L as urndis0
Not sure if this is entirely the correct way to go about
making this device work, or if this is even the correct place to
report this. But adding the following patch to my 6.4-STABLE
system got things working correctly (IPv4 and IPv6):
---
Index: sys/dev/usb/if_urndis.c
===
RCS file: /cvs/src/sys/dev/usb/if_urndis.c,v
retrieving revision 1.68
diff -u -p -u -r1.68 if_urndis.c
--- sys/dev/usb/if_urndis.c 2 Oct 2018 19:49:10 - 1.68
+++ sys/dev/usb/if_urndis.c 19 Feb 2019 00:50:24 -
@@ -130,7 +130,8 @@ const struct urndis_class {
} urndis_class[] = {
{ UICLASS_CDC, UISUBCLASS_ABSTRACT_CONTROL_MODEL, 0xff, "Vendor" },
{ UICLASS_WIRELESS, UISUBCLASS_RF, UIPROTO_RNDIS, "RNDIS" },
- { UICLASS_MISC, UISUBCLASS_SYNC, UIPROTO_ACTIVESYNC, "Activesync" }
+ { UICLASS_MISC, UISUBCLASS_SYNC, UIPROTO_ACTIVESYNC, "Activesync" },
+ { UICLASS_MISC, 0x04, 0x01, "RNDIS" }
};
usbd_status
---
And here are some relevant outputs I've seen posted
before related to getting such devices working in case there is a
better way to match this device. Let me know if you want
anything else:
---
# dmesg | tail -20 | grep^u
urndis0 at uhub0 port 2 configuration 1 interface 0 "Novatel Wireless MiFi
8800L" rev 3.10/3.18 addr 2
urndis0: using RNDIS, address 00:15:ff:26:73:70
umodem0 at uhub0 port 2 configuration 1 interface 12 "Novatel Wireless MiFi
8800L" rev 3.10/3.18 addr 2
umodem0: data interface 13, has no CM over data, has no break
umodem0: status change notification available
ucom0 at umodem0
uhidev0 at uhub0 port 2 configuration 1 interface 14 "Novatel Wireless MiFi
8800L" rev 3.10/3.18 addr 2
uhidev0: iclass 3/0
uhid0 at uhidev0: input=4, output=4, feature=0
ugen0 at uhub0 port 2 configuration 1 "Novatel Wireless MiFi 8800L" rev
3.10/3.18 addr 2
uhub2 at uhub1 port 1 configuration 1 interface 0 "Advanced Micro Devices
product 0x7900" rev 2.00/0.18 addr 2
# usbdevs -a 2 -d /dev/usb0 -v
addr 02: 1410:b023 Novatel Wireless, MiFi 8800L
super speed, power 224 mA, config 1, rev 3.18, iSerialNumber
0123456789ABCDEF
driver: urndis0
driver: umodem0
driver: uhidev0
driver: ugen0
# usbctl -a 2 -d /dev/usb0
DEVICE addr 2
DEVICE descriptor:
bLength=18 bDescriptorType=device(1) bcdUSB=3.10 bDeviceClass=0
bDeviceSubClass=0
bDeviceProtocol=0 bMaxPacketSize=9 idVendor=0x1410 idProduct=0xb023
bcdDevice=318
iManufacturer=1(Novatel Wireless) iProduct=2(MiFi 8800L)
iSerialNumber=3(0123456789ABCDEF) bNumConfigurations=1
CONFIGURATION descriptor 0:
bLength=9 bDescriptorType=config(2) wTotalLength=345 bNumInterface=8
bConfigurationValue=1 iConfiguration=0() bmAttributes=80 bMaxPower=224 mA
Unknown descriptor (class 0/0):
bLength=8 bDescriptorType=11 ...
INTERFACE descriptor 0:
bLength=9 bDescriptorType=interface(4) bInterfaceNumber=0 bAlternateSetting=0
bNumEndpoints=1 bInterfaceClass=239 bInterfaceSubClass=4
bInterfaceProtocol=1 iInterface=6(RNDIS Communications Control)
Unknown descriptor (class 239/4):
bLength=5 bDescriptorType=36 ...
Unknown descriptor (class 239/4):
bLength=5 bDescriptorType=36 ...
Unknown descriptor (class 239/4):
bLength=4 bDescriptorType=36 ...
Unknown descriptor (class 239/4):
bLength=5 bDescriptorType=36 ...
ENDPOINT descriptor:
bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=1-in
bmAttributes=interrupt wMaxPacketSize=8 bInterval=9
Unknown descriptor (class 239/4):
bLength=6 bDescriptorType=48 ...
INTERFACE descriptor 1:
bLength=9 bDescriptorType=interface(4) bInterfaceNumber=1 bAlternateSetting=0
bNumEndpoints=2 bInterfaceClass=10 bInterfaceSubClass=0
bInterfaceProtocol=0 iInterface=7(RNDIS Ethernet Data)
ENDPOINT descriptor:
bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=14-in
bmAttributes=bulk wMaxPacketSize=1024 bInterval=0
Unknown descriptor (class 10/0):
bLength=6 bDescriptorType=48 ...
ENDPOINT descriptor:
bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=15-out
bmAttributes=bulk wMaxPacketSize=1024 bInterval=0
Unknown descriptor (class 10/0):
bLength=6 bDescriptorType=48 ...
INTERFACE descriptor 2:
bLength=9 bDescriptorType=interface(4) bInterfaceNumber=2 bAlternateSetting=0
bNumEndpoints=3 bInterfaceClass=255 bInterfaceSubClass=0
bInterfaceProtocol=0 iInterface=0()
Unknown descriptor (class 255/0):
bLength=5 bDescriptorType=36 ...
Unknown descriptor (class 255/0):
bLength=5 bDescriptorType=36 ...
Unknown descriptor (class 255/0):
bLength=4 bDescriptorType=36 ...
Unknown descriptor (class 255/0):
bLength=5 bDescriptorType=36 ...
ENDPOINT descriptor:
bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=3-in
bmAttributes=interrupt wMaxPacketSize=10 bInterval=9
Unknown descriptor (class 255/0):
bLength=6 bDescriptorType=48 ...
ENDPOINT descriptor:
bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=2-in
bmAttributes=bulk wMaxPacketSize=1024 bInterval=0
Unknown descriptor (class 255/0):
Re: PPPoE vlan issue 6.4
To follow up in case anyone has similar issues in the future I have now got this working. It appears I had several issues. 1) ISP documentation stating to use VLAN2 This appears to be incorrect for my ISP. I had vlan2 set up on my DD-WRT router, when doing a TCP dump on the router I could see PPPoE traffic over vlan2 however when I plugged the router into another machine to tcpdump on the other end the VLAN was being stripped. This was what initially was misleading me. Disabling vlan2 on my setup for PPPoE resolved the issue where I was not getting any PADO responses from the PADI packets. 2) No IPv6 configured on the PPPoE interface During the PPPoE negotiation, my ISP sends an IPv6 address. This causes the PPP implementation to try and open an IPv6 interface which does not exist: "pppoe0: ipv6cp_open(): no IPv6 interface". This then results in OpenBSD sending a disconnect packet "pppoe0: lcp close(opened)" which then cancels the whole PPPoE initialization as the remote receives a disconnect. I've only read the PPPoE spec enough to debug my issue but I'm not sure a disconnect should be sent at this stage anyway as it prevents getting to the IPv4 address negotiation. To resolve the no IPv6 "ipv6cp_open(): no IPv6 interface" issue I needed to add an IPv6 statement to my /etc/hostname.pppoe0 file 3) IPv4 address not agreed error "ipcp parse opt values: address 10.20.21.253 [not agreed] send conf-nak" This looked strange, in my PPPoE config I had "inet 0.0.0.0 255.255.255.255" which means the interface should accept any address given. I then tried looking at the "sys/net/if_pppoe.c" and tracing back from there. Eventually, I discovered I had a subtle config issue in my /etc/hostname.pppoe file, mtu and llprio where on new lines: inet 0.0.0.0 255.255.255.255 NONE \ pppoedev em0 authproto pap \ authname 'username' authkey 'password' mtu 1492 llprio 1 dest 0.0.0.1 inet6 eui64 !/sbin/route add default -ifp pppoe0 0.0.0.1 !/sbin/route add ::/0 -ifp pppoe0 fe80::%pppoe0 Changing to the below resolved the issue: inet 0.0.0.0 255.255.255.255 NONE mtu 1492 llprio 1 \ pppoedev em0 authproto pap \ authname 'username' authkey 'password' dest 0.0.0.1 inet6 eui64 !/sbin/route add default -ifp pppoe0 0.0.0.1 !/sbin/route add ::/0 -ifp pppoe0 fe80::%pppoe0 Finally I had an active PPPoE connection. Hope this helps anyone in the future. -- Adam Evans On Sun, 10 Feb 2019, at 16:51, Adam Evans wrote: > Some more debugging, a lot further but still no success. > > I attached the DD-WRT modem directly to a computer to capture the PADI > packets. > > Capturing from the DD-WRT modem directly, PADI packets look like the below: > > 22:15:54.329145 a0:63:91:47:81:07 (oui Unknown) > Broadcast, ethertype > 802.1Q (0x8100), length 36: vlan 2, p 0, ethertype PPPoE D, PPPoE PADI > [Service-Name] [Host-Uniq 0xEE72] > 0x: 0002 8863 1109 000c 0101 > 0103 ...c > 0x0010: 0004 ee72 ...r.. > > > On the other end of the wire at the client the packets look like: > 12:13:05.995412 a0:63:91:47:81:07 (oui Unknown) > Broadcast, ethertype > PPPoE D (0x8863), length 60: PPPoE PADI [Service-Name] [Host-Uniq > 0x622A] > 0x: 1109 000c 0101 0103 0004 622a ..b* > 0x0010: > 0x0020: 838c 7a4d zM > > 12:13:20.277749 a0:63:91:47:81:07 (oui Unknown) > Broadcast, ethertype > PPPoE D (0x8863), length 60: PPPoE PADI [Service-Name] [Host-Uniq > 0xF02A] > 0x: 1109 000c 0101 0103 0004 f02a ...* > 0x0010: > 0x0020: e929 b08f ...).. > > From the above it looks like the PPPoE Discovery is not done over the > vlan as it get's stripped. > > I updated the /etc/hostname.pppoe0 config to change pppodev from vlan2 > to em0. I then plugged the device in to the bridged modem and brought up > the PPPoE interface which returned the below. I do not have IPv6 setup > in my PPPoE config so it looks like the remote tries to send me a IPv6 > packet which causes OpenBSD to send a terminate session response. > > # ifconfig pppoe0 up > Feb 10 13:18:48 foo /bsd: pppoe0: lcp close(initial) > Feb 10 13:18:48 foo /bsd: pppoe0: lcp open(initial) > Feb 10 13:18:48 foo /bsd: pppoe0: lcp initial->starting > Feb 10 13:18:48 foo /bsd: pppoe0: phase establish > Feb 10 13:18:48 foo /bsd: pppoe0 (8863) state=1, session=0x0 output -> > ff:ff:ff:ff:ff:ff, len=18 > Feb 10 13:18:48 foo /bsd: pppoe0 (8863) state=2, session=0x0 output -> > 78:da:6e:de:db:d4, len=38 > Feb 10 13:18:48 foo /bsd: pppoe0: received unexpected PADO > Feb 10 13:18:48 foo last message repeated 10 times > Feb 10 13:18:48 foo /bsd: pppoe0: session 0xe84d connected > Feb 10 13:18:48 foo /bsd:
Re: Turn off athn0
‐‐‐ Original Message ‐‐‐ On Monday, February 18, 2019 8:31 PM, Stefan Sperling wrote: > Yes, putting the interface down will disable radio. Thanks Stefan for your answer, always so helpful and efficient ;-)
Re: Turn off athn0
On Mon, Feb 18, 2019 at 07:23:31PM +, mabi wrote: > Hello, > > I have an Atheros AR9280 miniPCI card acting as a WIFI hotspot on my OpenBSD > firewall and would like to turn it off during a specific time window of the > day. > > To turn it completely off (no waves) would a crontab entry using the > following command be enough? > > ifconfig athn0 down > > or do I need any other commands in order to switch it completely off? > > Regards, > Mabi Yes, putting the interface down will disable radio.
Turn off athn0
Hello, I have an Atheros AR9280 miniPCI card acting as a WIFI hotspot on my OpenBSD firewall and would like to turn it off during a specific time window of the day. To turn it completely off (no waves) would a crontab entry using the following command be enough? ifconfig athn0 down or do I need any other commands in order to switch it completely off? Regards, Mabi
Re: ssd drive disappears when booting
On 2/17/19 2:57 AM, Jason McIntyre wrote: > On Sun, Feb 17, 2019 at 01:23:44AM +, tfrohw...@fastmail.com wrote: ... >> This sounds like the problem that I (and others) have seen when the hard >> drive is set to RAID in the Bios/firmware. Try setting it to AHCI if your >> bios lets you. >> > > wow, that was exactly it! i don;t understand how it was running one > minute, and then changed, but setting the drive to ahci worked (it was > indeed parked on raid). > > thanks so much - you just saved me a ton of hassle. > > jmc > > OpenBSD 6.4-current (GENERIC.MP) #713: Wed Feb 13 22:35:28 MST 2019 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP ... > bios0: vendor Dell Inc. version "A15" date 08/15/2012 Your CMOS battery is dying. I've got a Dell a bit newer than yours with the same problem -- under circumstances I haven't quite figured out, the CMOS resets to default, which, oddly, is RAID. Nick.
OpenBSD HTTPD and yourls
Hello guys, Please anyone already deployed yourls with OpenBSD HTTPD? I´m having issues with url rewrite. Any direction will be appreciated. Thanks in advance.
Re: How do I enable isochronous transfer in xhci(4)?
On Mon, Feb 18, 2019 at 04:56:41PM +0200, Leonid Bobrov wrote: > On Mon, Feb 18, 2019 at 11:59:30AM +0200, Leonid Bobrov wrote: > > On Sun, Feb 17, 2019 at 11:44:03PM -, Stuart Henderson wrote: > > > If you need to ask how to enable it, it really isn't going to be useful > > > for you, it's pretty obvious in xhci.c. > > > > > > > Oh, ok, I'll check it out. > > > > Enabling isochronous transfers in xhci(4) made my UBS 2.0 webcam work at > my computer, but for some reason that same webcam doesn't work at my > laptop. And yes, built-in laptop webcam doesn't work too. According to your computer's dmesg the webcam was attached via ehci(4) instead of xhci(4): ehci0 -> usb1 -> uhub1 -> uvideo0 > ehci0 at pci0 dev 18 function 2 "AMD Hudson-2 USB2" rev 0x11: apic 0 int 17 > usb1 at ehci0: USB revision 2.0 > uhub1 at usb1 configuration 1 interface 0 "AMD EHCI root hub" rev 2.00/1.00 > addr 1 > uvideo0 at uhub1 port 2 configuration 1 interface 0 "Aveotek GEMIX WEBCAM USB > AUDIO" rev 2.00/3.11 addr 2
Re: How do I enable isochronous transfer in xhci(4)?
On Mon, Feb 18, 2019 at 11:59:30AM +0200, Leonid Bobrov wrote: > On Sun, Feb 17, 2019 at 11:44:03PM -, Stuart Henderson wrote: > > If you need to ask how to enable it, it really isn't going to be useful > > for you, it's pretty obvious in xhci.c. > > > > Oh, ok, I'll check it out. > Enabling isochronous transfers in xhci(4) made my UBS 2.0 webcam work at my computer, but for some reason that same webcam doesn't work at my laptop. And yes, built-in laptop webcam doesn't work too. I'll attach dmesg(8) output from both my computer and my laptop, I hope that's helpful: OpenBSD 6.4-current (GENERIC.MP) #0: Mon Feb 18 16:33:59 EET 2019 mazoc...@mazocomp.lan:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 7457595392 (7112MB) avail mem = 7221878784 (6887MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xecd20 (55 entries) bios0: vendor American Megatrends Inc. version "V8.1" date 04/15/2015 bios0: MSI MS-7721 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET UEFI IVRS SSDT SSDT CRAT SSDT SSDT acpi0: wakeup devices SBAZ(S4) ECIR(S4) P0PC(S4) OHC1(S4) EHC1(S4) OHC2(S4) EHC2(S4) OHC3(S4) EHC3(S4) OHC4(S4) PE20(S4) PE21(S4) PE23(S4) PB21(S4) PB22(S4) PB31(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 16 (boot processor) cpu0: AMD A8-7650K Radeon R7, 10 Compute Cores 4C+6G, 3296.28 MHz, 15-30-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,DBKP,PERFTSC,ITSC,FSGSBASE,BMI1,XSAVEOPT cpu0: 96KB 64b/line 3-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 17 (application processor) cpu1: AMD A8-7650K Radeon R7, 10 Compute Cores 4C+6G, 3293.84 MHz, 15-30-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,DBKP,PERFTSC,ITSC,FSGSBASE,BMI1,XSAVEOPT cpu1: 96KB 64b/line 3-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 18 (application processor) cpu2: AMD A8-7650K Radeon R7, 10 Compute Cores 4C+6G, 3293.84 MHz, 15-30-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,DBKP,PERFTSC,ITSC,FSGSBASE,BMI1,XSAVEOPT cpu2: 96KB 64b/line 3-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache cpu2: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 19 (application processor) cpu3: AMD A8-7650K Radeon R7, 10 Compute Cores 4C+6G, 3293.85 MHz, 15-30-01 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,DBKP,PERFTSC,ITSC,FSGSBASE,BMI1,XSAVEOPT cpu3: 96KB 64b/line 3-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache cpu3: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu3: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 21, 24 pins ioapic1 at mainbus0: apid 1 pa 0xfec01000, version 21, 32 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (P0PC) acpiprt2 at acpi0: bus -1 (PE20) acpiprt3 at acpi0: bus -1 (PE21) acpiprt4 at acpi0: bus -1 (PE23)
[no subject]
subscribe misc
Re: How do I enable isochronous transfer in xhci(4)?
On Sun, Feb 17, 2019 at 11:44:03PM -, Stuart Henderson wrote: > If you need to ask how to enable it, it really isn't going to be useful > for you, it's pretty obvious in xhci.c. > Oh, ok, I'll check it out. > You can try disabling XHCI / USB 3 in BIOS if you have that option, or > "boot -c" at the boot loader, "disable xhci", "quit" to knock out the > driver, if you're lucky then a USB 2 driver will attach instead. > That used to work on my main workstation but doesn't any more > (kills the keyboard too). > I know about that trick, it attaches ehci(4) to USB 2 webcams (I have one, but why isn't that a default?), but the problem is it doesn't attach to webcam built into my laptop and that's the main problem.
Conexant CX20641/CX20651 audio driver
Hello, I am trying to see if OpenBSD has support for this audio chipset. Man page does not mention this explicitly, not so much to find on the web. May be that ac97 driver is enough for it? Can anyone tell if this will work or not in OpenBSD, please? Thank you.
Is there a fix for stock vi's bug-for-bug compatible ESC-equals-return feature?
BACKGROUND: When I use vi on OpenBSD, I use stock vi (which is nvi) instead of installing vim, because: (1), I haven't outgrown plain vanilla vi yet, and (2), while still learning, I'm trying not to pick up vim habits and create a dependency on vim-only features, since stock vi is on every OpenBSD, etc. box but vim may not always be available. PROBLEM: vi(1) has a feature where pressing ESC while in command-line mode (i.e. entering an ex command in command mode) will sometimes cancel the current line of ex input, but other times will have the same effect as if the user had pressed return. DISCUSSION: This is a documented behaviour. Whether ESC cancels or works like return in command-line mode depends on whether what the user has typed so far can already be considered a complete ex command. >From man 1 vi: > ⟨escape⟩ > Execute the ex command being entered, or cancel it if it is only partial. While this feature/bug is counter-intuitive (IMHO), I presume nvi acts this way so as to be bug-for-bug compatible with original vi. (That's my guess. I haven't actually confirmed this.) Either way, if the user presses ESC to cancel a complete :x command, the result may be unexpected. QUESTION: Is there any fix for this (IMHO undesirable) ESC-equals-return behaviour in vi? Other than installing vim, which does not act this way, at least not by default? FLUFF: If not, then this may be the point where I do outgrow nvi. *shrugs* Alternatively, if there is no fix and if I continue to be unwilling to graduate to vim, would patches to OpenBSD's stock vi be welcome? (I sincerely doubt I'd be able to produce a patch, especially one anywhere close to a quality acceptable to OpenBSD; I'd really struggle with that, and for a long time too, so I'm just checking if the idea of a vi patch for something like an option to make ESC always cancel would already be dismissed out of hand anyway, because beware feeping creaturism.)
