Re: gnome, gdm problem on lenovo e14 gen2
Hrvoje Popovski writes: > Problem is that when i should get login screen, gdm to ask me for user > and password, i'm getting blank grey screen .. > > after moving through terminals with ctrl-alt fX, from time to time i can > get this (screenshot below) > https://kosjenka.srce.hr/~hrvoje/openbsd/gdm1.jpg > https://kosjenka.srce.hr/~hrvoje/openbsd/gdm2.jpg > > in both cases, i can't click on anything in login screen .. > > I'm not much of a desktop user and if someone have clue what i'm doing > wrong please tell me :) Thanks for reporting this. I also get this with my radeon 6850 where the screen is grey. If I switch back and forth through terminals I might eventually get the screen to render. Nothing is clickable. In contrast gnome works on my thinkpad x230i, which uses intel(4).
Re: Can I shorten fw_update download timeout?
On 2021-04-08, Luke Small wrote: > I make unbound connect to dnscrypt-proxy and after an update, it’ll just > sit there for what seems like 2 minutes while fw_update inevitably fails > before turning on dnscrypt-proxy. I’ve been running snapshots and that’s > really dumb. Or is there a way to have unbound connect to a failover server > when the default resolver isn’t responsive that I’m not aware of?-- > -Luke > You can have >=0 forward-addr lines. >From unbound.conf(5): "There may be multiple forward-zone: clauses. Each with a name: and zero or more hostnames or IP addresses."
Re: What TERM fixes Emacs?
On 2020-02-25, Raymond, David wrote: > Maybe there is some mechanism for setting the alt key to meta > in emacs on consoles, but I use X11 so I haven't needed to pursue > this. matthieu@ pointed out how to use the alt key in console emacs. Source: https://marc.info/?l=openbsd-misc&m=91345235818444&w=2 (set-input-mode t nil t) Thanks sthen@ for the pccon hint. emacs looks better in console now.
Re: Requesting vi tips
On 2019-10-18, Christian Weisgerber wrote: > On 2019-10-18, cho...@jtan.com wrote: > >> I didn't know [how] ! took movement commands. Thanks. I'll have a play >> with that one. >> >> It's not quite M-q (it's M not C) but I'm using vi after all. > > Since 'q' is unused in nvi, I have this in my .nexrc: > > map q !}fmt > > Close enough to emacs's M-q. > I just wanted to add that you can Ctrl-v Enter to produce the ^M at the end. This way it inputs and executes the command for you. It could be like this if you want it to press Enter for you: map q !}fmt^M I like joining lines before using fmt on a single line, hence the '.'. I had forgotten about the '}' motion and may need to incorporate that. I also did not know that the ':' can be omitted. I currently use: map gq :.!fmt -w 72^M map q0 :.!fmt -w 77^M map q1 :.!fmt -w 69^M map q2 :.!fmt -w 61^M map q3 :.!fmt -w 53^M map qq :.!fmt -w 80^M
Re: xhci isochronous transfers
Alexandre Ratchov writes: > On Sat, Mar 16, 2019 at 06:58:55PM -0700, Nam Nguyen wrote: >> >> > This procedure is sufficient when I use a USB 2 port. >> >> I forgot to test USB 2 at the time of my original e-mail. There is >> actually a regression and both USB 2 and USB 3 ports throw the same >> error. >> >> --8<---cut here---start->8--- >> uaudio0: can't get iface handle >> uaudio0: can't get iface handle >> audio1: failed to start playback >> uaudio0: can't get iface handle >> --8<---cut here---end--->8--- > > This this caused by the uaudio driver itself. Could you send me the > dmesg output of a kernel with UAUDIO_DEBUG defined? > > Thanks in advance. This is with the DAC attached to USB 3. --8<---cut here---start->8--- OpenBSD 6.5-beta (GENERIC) #0: Sun Mar 17 21:40:48 PDT 2019 namt...@dust2.my.domain:/sys/arch/amd64/compile/GENERIC real mem = 16872108032 (16090MB) avail mem = 16350568448 (15593MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (69 entries) bios0: vendor LENOVO version "G2ET33WW (1.13 )" date 07/24/2012 bios0: LENOVO 2306CTO acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT ASF! UEFI UEFI POAT SSDT SSDT UEFI acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i3-3120M CPU @ 2.50GHz, 2494.79 MHz, 06-3a-09 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,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 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu at mainbus0: not configured ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus -1 (EXP3) acpicpu0 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PUBS, resource for XHCI, EHC1, EHC2 acpitz0 at acpi0: critical temperature is 103 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 tpm0 at acpi0: TPM_ addr 0xfed4/0x5000: device 0x104a rev 0x4e acpibat0 at acpi0: BAT0 model "45N1023" serial 4025 type LION oem "SANYO" acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured acpidock0 at acpi0: GDCK not docked (0) acpivideo0 at acpi0: VID_ acpivout at acpivideo0 not configured acpivideo1 at acpi0: VID_ cpu0: Enhanced SpeedStep 2494 MHz: speeds: 2500, 2400, 2300, 2200, 2100, 2000, 1900, 1800, 1700, 1600, 1500, 1400, 1300, 1200 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 3G Host" rev 0x09 inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 4000" rev 0x09 drm0 at inteldrm0 inteldrm0: msi inteldrm0: 1366x768, 32bpp wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) xhci0 at pci0 dev 20 function 0 "Intel 7 Series xHCI" rev 0x04: msi, xHCI 1.0 usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1 "Intel 7 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x04: msi, address 3c:97:0e:36:95:a5 ehci0 at pci0 dev 26 function 0 "Intel 7 Series USB" rev 0x04: apic 2 int 16 usb1 at ehci0: USB revision 2.0 uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 "Intel 7 Series HD Audio" rev 0x04: msi azalia0: codecs: Realtek ALC269, Intel/0x2806, using Realtek ALC269 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 "Intel 7 Series PCIE" rev 0xc4: msi pci1 at ppb0 bus 2 sdhc0 at pci1 dev 0 function 0 "Ricoh 5U822 SD/MMC" rev 0x07: apic 2 int 16 sdhc0: SDHC 3.0, 50 MHz base
Re: xhci isochronous transfers
> This procedure is sufficient when I use a USB 2 port. I forgot to test USB 2 at the time of my original e-mail. There is actually a regression and both USB 2 and USB 3 ports throw the same error. --8<---cut here---start->8--- uaudio0: can't get iface handle uaudio0: can't get iface handle audio1: failed to start playback uaudio0: can't get iface handle --8<---cut here---end--->8---
Re: xhci isochronous transfers
Thank you for all the work that went into this. I am testing USB 3 on a Thinkpad x230i for my headphone DAC, an ODAC-revB. I tested a Youtube video, and it does not begin playback. The relevant error is at the end of the pasted dmesg. I also tested this on a Thinkpad X1 Carbon Gen 4 to the same result, but that dmesg is omitted for brevity. I tried setting sndiod to use the DAC, as described in the FAQs (https://www.openbsd.org/faq/faq13.html#confaudio). This procedure is sufficient when I use a USB 2 port. --8<---cut here---start->8--- # rcctl set sndiod flags -f rsnd/1 # rcctl restart sndiod --8<---cut here---end--->8--- full dmesg: --8<---cut here---start->8--- OpenBSD 6.5-beta (GENERIC.MP) #798: Sat Mar 16 10:12:15 MDT 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16872108032 (16090MB) avail mem = 16350453760 (15593MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (69 entries) bios0: vendor LENOVO version "G2ET33WW (1.13 )" date 07/24/2012 bios0: LENOVO 2306CTO acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT ASF! UEFI UEFI POAT SSDT SSDT UEFI acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i3-3120M CPU @ 2.50GHz, 2494.75 MHz, 06-3a-09 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,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 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i3-3120M CPU @ 2.50GHz, 2494.34 MHz, 06-3a-09 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus -1 (EXP3) acpicpu0 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PUBS, resource for XHCI, EHC1, EHC2 acpitz0 at acpi0: critical temperature is 103 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 tpm0 at acpi0: TPM_ addr 0xfed4/0x5000: device 0x104a rev 0x4e acpibat0 at acpi0: BAT0 model "45N1023" serial 4025 type LION oem "SANYO" acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured acpidock0 at acpi0: GDCK not docked (0) acpivideo0 at acpi0: VID_ acpivout at acpivideo0 not configured acpivideo1 at acpi0: VID_ cpu0: Enhanced SpeedStep 2494 MHz: speeds: 2500, 2400, 2300, 2200, 2100, 2000, 1900, 1800, 1700, 1600, 1500, 1400, 1300, 1200 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 3G Host" rev 0x09 inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 4000" rev 0x09 drm0 at inteldrm0 inteldrm0: msi inteldrm0: 1366x768, 32bpp wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) xhci0 at pci0 dev 20 function 0 "Intel 7 Series xHCI" rev 0x04: msi, xHCI 1.0 usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1 "Intel 7 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x04: msi, address 3c:97:0e:36:95:a5 ehci0 at pci0 dev 26 function 0 "Intel 7 Series USB" rev 0x04: apic 2 int 16 usb1 at ehci0: USB revision 2.0 uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 "Intel 7 Series HD Audio" rev 0x04: msi azalia0: codecs: Realtek ALC269, Intel/0x2
Re: [patch] cwm group-delete
Hi Okan, Okan Demirmen writes: > Additionally, I'm not sure I like 'delete' as in 'group-delete-[n]'; yes > right now there is a 'window-delete', but that should be 'window-close' > (I'll alias that shortly). Yes, I based the name on `window-delete'. `group-close' and `window-close' sound like suitable names. >> XKillClient(3) is a big hammer; is there a reason why client_send_delete() >> wasn't used? client_send_delete() will call XKillClient(3) if the client >> doesn't support the WM_DELETE_WINDOW property. If there's no specific >> reason, no need to re-send a diff. I was not aware of all the options and was cargo-culting in general. I was satisfied once I found any way to close the window. Thank you for the explanation and review. Feel free to edit it however you see fit.
Re: cvsweb.openbsd.org - same as cvsweb in ports?
Adam Thompson writes: > What version of cvsweb does cvsweb.openbsd.org run? And where is that > software available? It appears to not quite be the same as cvsweb in > ports, so... ? It looks the same to me, other than some customized CSS. You can see the log here: https://cvsweb.openbsd.org/ports/devel/cvsweb/Makefile
[patch] cwm group-delete
This patch for cwm adds group-delete to delete all windows in a group. I
usually end up with many disposable windows in a group, so this makes it
easier to manage them.
The main function added is group_delete(struct screen_ctx *sc, int idx).
Index: calmwm.h
===
RCS file: /cvs/xenocara/app/cwm/calmwm.h,v
retrieving revision 1.362
diff -u -p -r1.362 calmwm.h
--- calmwm.h8 Nov 2018 15:49:42 - 1.362
+++ calmwm.h23 Jan 2019 08:09:36 -
@@ -451,6 +451,7 @@ int group_holds_only_sticky(struct gr
voidgroup_init(struct screen_ctx *, int);
voidgroup_movetogroup(struct client_ctx *, int);
voidgroup_only(struct screen_ctx *, int);
+voidgroup_delete(struct screen_ctx *, int);
int group_restore(struct client_ctx *);
voidgroup_show(struct group_ctx *);
voidgroup_toggle_membership(struct client_ctx *);
@@ -508,6 +509,7 @@ void
kbfunc_client_toggle_group(void
voidkbfunc_client_movetogroup(void *, struct cargs *);
voidkbfunc_group_toggle(void *, struct cargs *);
voidkbfunc_group_only(void *, struct cargs *);
+voidkbfunc_group_delete(void *, struct cargs *);
voidkbfunc_group_cycle(void *, struct cargs *);
voidkbfunc_group_alltoggle(void *, struct cargs *);
voidkbfunc_menu_client(void *, struct cargs *);
Index: conf.c
===
RCS file: /cvs/xenocara/app/cwm/conf.c,v
retrieving revision 1.242
diff -u -p -r1.242 conf.c
--- conf.c 13 Nov 2018 17:37:13 - 1.242
+++ conf.c 23 Jan 2019 08:09:36 -
@@ -143,6 +143,15 @@ static const struct {
{ FUNC_SC(group-only-7, group_only, 7) },
{ FUNC_SC(group-only-8, group_only, 8) },
{ FUNC_SC(group-only-9, group_only, 9) },
+ { FUNC_SC(group-delete-1, group_delete, 1) },
+ { FUNC_SC(group-delete-2, group_delete, 2) },
+ { FUNC_SC(group-delete-3, group_delete, 3) },
+ { FUNC_SC(group-delete-4, group_delete, 4) },
+ { FUNC_SC(group-delete-5, group_delete, 5) },
+ { FUNC_SC(group-delete-6, group_delete, 6) },
+ { FUNC_SC(group-delete-7, group_delete, 7) },
+ { FUNC_SC(group-delete-8, group_delete, 8) },
+ { FUNC_SC(group-delete-9, group_delete, 9) },
{ FUNC_SC(pointer-move-up, ptrmove, (CWM_UP)) },
{ FUNC_SC(pointer-move-down, ptrmove, (CWM_DOWN)) },
Index: cwmrc.5
===
RCS file: /cvs/xenocara/app/cwm/cwmrc.5,v
retrieving revision 1.70
diff -u -p -r1.70 cwmrc.5
--- cwmrc.5 29 Dec 2017 20:03:46 - 1.70
+++ cwmrc.5 23 Jan 2019 08:09:37 -
@@ -288,6 +288,8 @@ menu.
Toggle visibility of group n, where n is 1-9.
.It group-only-[n]
Show only group n, where n is 1-9, hiding other groups.
+.It group-delete-[n]
+Delete windows in group n, where n is 1-9.
.It group-toggle-all
Toggle visibility of all groups.
.It window-group
Index: group.c
===
RCS file: /cvs/xenocara/app/cwm/group.c,v
retrieving revision 1.128
diff -u -p -r1.128 group.c
--- group.c 23 Jan 2018 13:48:49 - 1.128
+++ group.c 23 Jan 2019 08:09:37 -
@@ -250,6 +250,24 @@ group_only(struct screen_ctx *sc, int id
}
void
+group_delete(struct screen_ctx *sc, int idx)
+{
+ struct group_ctx*gc;
+ struct client_ctx *cc;
+
+ if (idx < 0 || idx >= Conf.ngroups)
+ return;
+
+ TAILQ_FOREACH(gc, &sc->groupq, entry) {
+ if (gc->num == idx) {
+ TAILQ_FOREACH(cc, &gc->clientq, group_entry) {
+ XKillClient(X_Dpy, cc->win);
+ }
+ }
+ }
+}
+
+void
group_cycle(struct screen_ctx *sc, int flags)
{
struct group_ctx*newgc, *oldgc, *showgroup = NULL;
Index: kbfunc.c
===
RCS file: /cvs/xenocara/app/cwm/kbfunc.c,v
retrieving revision 1.159
diff -u -p -r1.159 kbfunc.c
--- kbfunc.c29 Dec 2017 20:03:46 - 1.159
+++ kbfunc.c23 Jan 2019 08:09:37 -
@@ -440,6 +440,12 @@ kbfunc_group_only(void *ctx, struct carg
}
void
+kbfunc_group_delete(void *ctx, struct cargs *cargs)
+{
+ group_delete(ctx, cargs->flag);
+}
+
+void
kbfunc_group_cycle(void *ctx, struct cargs *cargs)
{
group_cycle(ctx, cargs->flag);
Re: Xbox 360 controller emulators/snes9x hangs at startup
> Can you compile a kernel with sys/dev/usb/uhid.c reverted to > older revisions to test your hypothesis? Compiling the kernel with a patch was a good learning exercise for me. I successfully applied mpi@'s patch, as posted in the other thread. To reiterate my results, Xbox 360 and PS3 controllers on snes9x and desmume work OK. > I encourage anyone affected to test the following patch and report > back success or failure: Thank you for pointing me to the relevant thread, as I did not think of searching ports@ before posting this. > Your system has both xhci(4) USB 3 and ehci(4) USB 2 ports. > Does it matter where the input devices are plugged? Good thing you brought this up because I tested on multiple laptops and never thought about USB 3 vs USB 2. This helped me uncover an unrelated bug, which is OT and unrelated to the original issue. When plugged into USB 3, the PS4 controller registers ghost input from the left analog stick, when I am not moving it. When plugged into USB 2, it does not exhibit this ghost input behavior. This could be a bug with xhci(4). But, this can be tabled for a future discussion, as the original issue was resolved. Back to playing games. -- Nam | PGP: 0x11B50169
Re: Xbox 360 controller emulators/snes9x hangs at startup
After further research, this commit[1][2] may explain what is going on.
> Remove SIGIO support. Base tools do not implement it and ports relying
> on libusbhid, generally via SDL, shouldn't do it either since it's not
> portable.
If I understand correctly, I should take up this issue with the
developers of the affected ports to not rely on this non-portable
code. Many emulators rely on SDL. I incorrectly viewed this as a
regression with uhid(4). Instead, it is a design decision by OpenBSD to
break backward compatibility, in favor of more portable code.
$ cd /usr/src
$ cvs diff -rOPENBSD_6_1 -rHEAD sys/dev/usb/uhid.c
Index: sys/dev/usb/uhid.c
===
RCS file: /cvs/src/sys/dev/usb/uhid.c,v
retrieving revision 1.66.6.1
retrieving revision 1.68
diff -u -p -r1.66.6.1 -r1.68
--- sys/dev/usb/uhid.c 1 Aug 2017 21:55:02 - 1.66.6.1
+++ sys/dev/usb/uhid.c 20 Jul 2017 16:54:45 - 1.68
@@ -1,4 +1,4 @@
-/* $OpenBSD: uhid.c,v 1.66.6.1 2017/08/01 21:55:02 bluhm Exp $ */
+/* $OpenBSD: uhid.c,v 1.68 2017/07/20 16:54:45 mpi Exp $ */
/* $NetBSD: uhid.c,v 1.57 2003/03/11 16:44:00 augustss Exp $ */
/*
@@ -237,7 +237,7 @@ uhidclose(dev_t dev, int flag, int mode,
DPRINTF(("uhidclose: sc=%p\n", sc));
clfree(&sc->sc_q);
- free(sc->sc_obuf, M_USBDEV, 0);
+ free(sc->sc_obuf, M_USBDEV, sc->sc_hdev.sc_osize);
uhidev_close(&sc->sc_hdev);
return (0);
Footnotes:
[1]
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/uhid.c?rev=1.68&content-type=text/x-cvsweb-markup
[2]
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/uhid.c.diff?r1=1.67&r2=1.68&f=h
--
Nam | PGP: 0x11B50169
Xbox 360 controller emulators/snes9x hangs at startup
On a -current snapshot <2017-09-18 Mon>, I am getting a bug in which
emulators/snes9x-1.54.1p0 hangs at startup, waiting for uhidread.
* Pre-requisites
One of the following: Xbox 360 controller / PS4 controller / external keyboard
Install emulators/snes9x
Run a -current snapshot
* To reproduce the bug
1. Plug in Xbox 360 controller.
2. Run snes9x-gtk from emulators/snes9x.
$ snes9x-gtk
Sound buffer size: 4096 (1024 samples)
SDL sound driver initializing...
--> (Frequency: 32000hz, Latency: 32ms)...OK
3. snes9x-gtk hangs at startup.
top shows that it is sleeping, waiting for uhidread. Eventually, it goes
to idle state.
PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND
0 0 35M45M sleep/2 uhidrea 0:01 1.32% snes9x-gtk
0 0 35M45M idle uhidrea 0:01 0.00% snes9x-gtk
4. Disconnect Xbox 360 controller. snes9x-gtk finishes loading.
PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND
2 0 35M45M onproc/0 poll 0:01 0.68% snes9x-gtk
2 0 35M45M sleep/1 poll 0:01 0.20% snes9x-gtk
* Observations
This bug is not specific to the Xbox 360 controller, because I was able
to reproduce this bug with an external keyboard and a PS4 controller. It
is also not specific to emulators/snes9x, because emulators/desmume
exhibits similar behavior after loading a ROM file.
I tested 6.0 -release and 6.1 -release, and emulators/snes9x
loaded OK with all controllers. This bug appeared once I updated to a
-current snapshot. My hypothesis is that -current introduced a
regression with uhid(4).
$ cd /usr/src/
$ grep -ir uhidrea* *
sys/dev/usb/uhid.c:DPRINTFN(1, ("uhidread\n"));
sys/dev/usb/uhid.c:DPRINTFN(5, ("uhidread: sleep on %p\n", &sc->sc_q));
sys/dev/usb/uhid.c:error = tsleep(&sc->sc_q, PZERO | PCATCH, "uhidrea", 0);
sys/dev/usb/uhid.c:DPRINTFN(5, ("uhidread: woke, error=%d\n", error));
sys/dev/usb/uhid.c:DPRINTFN(5, ("uhidread: got %zu chars\n", length));
sys/dev/usb/uhid.c:uhidread(dev_t dev, struct uio *uio, int flag)
sys/dev/usb/uhid.c:int filt_uhidread(struct knote *, long);
sys/dev/usb/uhid.c:filt_uhidread(struct knote *kn, long hint)
sys/dev/usb/uhid.c:struct filterops uhidread_filtops =
sys/dev/usb/uhid.c:{ 1, NULL, filt_uhidrdetach, filt_uhidread };
sys/dev/usb/uhid.c:kn->kn_fop = &uhidread_filtops;
$ dmesg
OpenBSD 6.2-beta (GENERIC.MP) #104: Mon Sep 18 23:31:27 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16872108032 (16090MB)
avail mem = 16353759232 (15596MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (69 entries)
bios0: vendor LENOVO version "G2ET33WW (1.13 )" date 07/24/2012
bios0: LENOVO 2306CTO
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT ASF!
UEFI UEFI POAT SSDT SSDT UEFI
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3)
EHC2(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i3-3120M CPU @ 2.50GHz, 2494.77 MHz
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 2494770320 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i3-3120M CPU @ 2.50GHz, 2494.33 MHz
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i3-3120M CPU @ 2.50GHz, 2494.33 MHz
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i3-3120M CPU @ 2.50GHz, 2494.33 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PA
Re: doas /usr/bin/vi best practice
If you are trying to avoid that message: > /home/just22/.exrc: not sourced: not owned by you It could be that you are in that in your home directory and vi is trying to read the local .exrc script on startup. In vi(1): > exrc, ex [off] > Read the startup files in the local directory. To turn off this feature, put "set noexrc" into your ~/.exrc The key is to understand what configuration files vi looks for when starting up. This is mentioned toward the bottom of vi(1). It seems like the precedence goes (from least to most): /etc/vi.exrc, ~/.exrc, ./.exrc. (For clarity, I am not including ~/.nexrc and ./.nexrc.) I used to have "set exrc" and would get the behavior you are describing, specifically while in my home directory. Disabling that feature with "set noexrc" removes ./.exrc from what vi scans for at startup. This is the setup I currently have. I have /etc/vi.exrc as a system-wide default vi configuration. In $HOME/.exrc I have general vi macros, and in $HOME/.nexrc I have programming language specific macros. Normally, what I will do is update ~/.exrc if I want to add some new features, and copy that to /etc/vi.exrc to have it available system-wide. Another observation I made was that because doas' default behavior is to reset the environment except for HOME, among others, executing `doas vi` gives me access to macros defined in both ~/.exrc ~/.nexrc even though I am root. If I change to root with `su` and then open `vi`, I only get access to /etc/vi.exrc and lose access to macros defined in ~/.nexrc. I have been annoyed by this problem, too, because I had to keep pressing enter to clear that error message, instead of the file instantaneously opening. I could not be bothered to investigate further until you had mentioned it.
