Re: gnome, gdm problem on lenovo e14 gen2

2021-05-04 Thread Nam Nguyen
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?

2021-04-24 Thread Nam Nguyen
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?

2020-02-28 Thread Nam Nguyen
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=91345235818444=2

(set-input-mode t nil t)

Thanks sthen@ for the pccon hint. emacs looks better in console now.



Re: Requesting vi tips

2019-10-18 Thread Nam Nguyen
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

2019-03-17 Thread Nam Nguyen
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 clock
sdmmc0 at

Re: xhci isochronous transfers

2019-03-16 Thread Nam Nguyen


> 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

2019-03-16 Thread Nam Nguyen


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, 

Re: [patch] cwm group-delete

2019-02-22 Thread Nam Nguyen


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?

2019-02-21 Thread Nam Nguyen
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

2019-01-23 Thread Nam Nguyen
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, >groupq, entry) {
+   if (gc->num == idx) {
+   TAILQ_FOREACH(cc, >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

2017-09-22 Thread Nam Nguyen
> 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

2017-09-22 Thread Nam Nguyen
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_q);
-   free(sc->sc_obuf, M_USBDEV, 0);
+   free(sc->sc_obuf, M_USBDEV, sc->sc_hdev.sc_osize);
uhidev_close(>sc_hdev);

return (0);

Footnotes:
[1]  
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/uhid.c?rev=1.68=text/x-cvsweb-markup
[2]  
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/uhid.c.diff?r1=1.67=1.68=h

-- 
Nam | PGP: 0x11B50169



Xbox 360 controller emulators/snes9x hangs at startup

2017-09-22 Thread Nam Nguyen
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_q));
sys/dev/usb/uhid.c:error = tsleep(>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 = _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: 

Re: doas /usr/bin/vi best practice

2017-08-13 Thread Nam Nguyen
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.