Enumerate uhid instances of uhidev

2019-08-05 Thread Anatoli

Hi Martin, all,

Could you please give a hint on how to enumerate all child uhid
instances of a given uhidev?

I'm trying to accomplish the following:

With hotplugd I get notifications for uhidev and uhid instances when I
attach a keyboard. I'd like to perform some action (usbhidaction -f
uhidX) on a specific uhid when a specific keyboard is attached.

I can get vendor/product IDs of the corresponding uhidev of the
keyboard with usbdevs -v (e.g. "driver: uhidev4"), but then I can't
find how to enumerate the uhid instances corresponding to a uhidev
instance.

Judging by struct usb_device_info, there's no way to get the uhid list
via USB_DEVICEINFO ioctl call and at the same time it looks like uhid
instances don't know about their parent uhidev (the info extracted by
usbhidctl). Is it at all possible to get this info? If it's currently
not possible without extending the drivers, I'd appreciate to know
this too.

Thanks,
Anatoli



Re: Host Header Redirection on openbsd.org

2019-08-05 Thread Marc Espie
Well, the main issue I've seen so far is you flooding my mailboxen with
lots of copies of the same useless mp4 video.

What a douche.



Re: Host Header Redirection on openbsd.org

2019-08-05 Thread Claus Assmann
On Mon, Aug 05, 2019, Marc Espie wrote:
> [[...]] the same useless mp4 video.

Maybe it is/contains an (attempt of an) exploit?

-- 
Address is valid for this mailing list only.



Re: Host Header Redirection on openbsd.org

2019-08-05 Thread Daniel Jakots
On Mon, 5 Aug 2019 05:38:46 -0700, Claus Assmann
 wrote:

> On Mon, Aug 05, 2019, Marc Espie wrote:
> > [[...]] the same useless mp4 video.  
> 
> Maybe it is/contains an (attempt of an) exploit?
> 

Unlikely since their signature says "Certified Ethical Hacker"



Re: Host Header Redirection on openbsd.org

2019-08-05 Thread Marc Espie
On Mon, Aug 05, 2019 at 08:59:46AM -0400, Daniel Jakots wrote:
> On Mon, 5 Aug 2019 05:38:46 -0700, Claus Assmann
>  wrote:
> 
> > On Mon, Aug 05, 2019, Marc Espie wrote:
> > > [[...]] the same useless mp4 video.  
> > 
> > Maybe it is/contains an (attempt of an) exploit?
> > 
> 
> Unlikely since their signature says "Certified Ethical Hacker"

The problem with security is that there are more wannabe attackers
than defenders.

(misquoting Theo)



Re: Advice for Users trying to help Driver Developers

2019-08-05 Thread Tom Smyth
Hi Stuart,
Thanks for getting back to me,

On Sun, 4 Aug 2019 at 00:53, Stuart Henderson  wrote:

> You can't easily look at a driver in isolation, the network performance
> you see involves various parts of the network stack common to all drivers.
> Quite a few of the network drivers are rather similar on several OS,
> but performance can differ hugely due to other aspects of the system.
>
I get what your saying, what i was trying to do was try to test in so
far as possible
the driver in terms of the output path (from iperf3 process) down
through the kernel
to the driver and out the nic)
and the reverse as as separate test

and if the machine hardware and OS setup was kept more or less constant and just
swap in the various types of NIC cards,
we might get a picture of how efficently the driver can pass packets
from the nic to the kernel
and vice versa (in a separate tests)

> > as far as I know  I need to provide developers
> > output of dmesg command,
> > debug output in the event of a crash (sendbug)
> >
> > compare performance under identical hardware conditions with different
> > Operating systems  eg using iperf3 / tcpbench
>
> (btw iperf3 is not a particularly good benchmark; on a fast network it
> often ends up measuring the speed of fetching time from the clock as
> much as anything else.. iperf 2.x or tcpbench usually give more useful
> results.
so is iperf3 too disruptive to the system under test that it cant
yield useful results at all ?
i

Also note if it's forwarding performance you're interested in,
> make sure you measure the right thing - run the packet generators/sinks
> on other fast machines routing or bridging through the machine under test,
> don't run them on the machine under test itself).

I was trying to narrow the test down to
Driver performance inbound path to a process on the machine
Driver performance outbound path  from a process on the machine

if the above tests are invalid in of them selves
Ill try doing a forwarding setup with an OpenBSD machine with 2 NICs
one NIC with a known driver and the other with the driver under test,
(this is easier with virtual machines)  (I was trying to avoid trying
to minimise the moving parts
in the test)  (i would be worreid that the known good driver its self
could be a bottleneck in the test)



> > Is it useful for devs to have users to collect and diff this data  and
> > present it
> > to devs,
> >

> Probably the thing that will help most is to keep an eye out for requests
> of testing of all sorts of diffs, test them and report back. Obviously
> anything related to drivers you use, but also diffs that say things like
> "unlock XX" or mention words like KERNEL_LOCK, NET_LOCK, mp-safe, etc.
> are all often on the path to increasing performance.
Ill try to do this in a more timely fashion

>
> Take a look at what Hrvoje Popovski has been doing in the way of testing
> (just look over the tech@ list archives, you'll find many examples), he
> has put in a lot of effort and the tests he's been doing are really useful.

Ill take a look at this Hrvoje has sent me advice on packet generators
Ill try them out

-- 
Kindest regards,
Tom Smyth.



Apple Display via Thunderbolt on macbook pro

2019-08-05 Thread John Brahy
Hello,

I have OpenBSD 6.5 installed on a MacBook Pro (mid-2015) and I was hoping
to use a couple of my 27" Apple Displays with it. Has anyone had any
success with them? I don't see anything pop up in dmesg when I plug them in
so not sure if the system detects them or of OpenBSD recognizes the
Thunderbolt bus. I see "Intel DSL 5520 Thunderbolt" rev 0x00 at pci4 dev 0
function 0 not configured in the dmesg.

Thanks,

John


Re: Multiple video cards in X?

2019-08-05 Thread Nick Holland
On 6/28/19 5:01 AM, Joe M wrote:
(yes, over a month ago...) 
> Hello,
> 
> I have multiple video cards (AMD Radeon) cards working with OpenBSD.
>  I have 2 monitors connected to each card (HDMI and DVI ports).
> 
> The issues are that I can use only fvwm and I cannot move x windows 
> across the video cards. I can move x windows across monitors 
> connected to the same video card though.
> 
> I tried to hack around the Xenocara codebase to figure out if I can 
> fix it. During my adventures, I realized that though Xenocara can be 
> modified to support this, the issue is in the radeon driver 
> (radeondrm, I think). At that point, I gave up as I did not have the 
> bandwidth to figure out how radeondrm works.
> 
> It took me quite a lot of time to figure out the correct 
> configuration. I was hoping that I could get cwm to work. But, I 
> could not. Only fvwm works. I did not bother to dig through why.
> 
> joe:10114$ cat /etc/X11/xorg.conf
> 
> # get the xorg.conf.firstcard and xorg.conf.secondcard to work # 
> startx # uses xorg.conf # cd /etc/X11; start -- :1 -config 
> xorg.conf.secondcard # to get the second card working # once both of
>  them work, below is bringing them together to show all monitors at 
> the same time
> 
> # leave out the monitor sections as the X fills up the holes
> 
> Section "ServerLayout" Identifier "Default Layout" Screen 0 "Screen 
> 0" Screen 1 "Screen 1" RightOf "Screen 0" EndSection
> 
> Section "Screen" Identifier "Screen 0" Device "Card 0" EndSection
> 
> Section "Device" Identifier "Card 0" Driver "radeon" BusID 
> "PCI:1:0:0" #Option "Monitor-HDMI-0" "HG281D" Option "Monitor-DVI-0"
>  "AL2223W" EndSection
> 
> Section "Monitor" Identifier "AL2223W" Option "LeftOf" "HDMI-0" 
> EndSection
> 
> Section "Screen" Identifier "Screen 1" Device "Card 1" EndSection
> 
> Section "Device" Identifier "Card 1" Driver "radeon" BusID 
> "PCI:11:0:0" EndSection
> 
> joe:10131$ tail -5 /home/j/.xsession
> 
> # cwm cannot spawn multiple cards # exec /usr/X11R6/bin/cwm exec 
> fvwm
> 
> Hope it helps.

Quite a bit, if nothing else, just gave me hope and a starting 
place!

Here's what I ended up with as a MINIMAL xorg.conf that seems to work
for me, with the same quirks you describe:
==
Section "ServerLayout"
Identifier "Default Layout"
Screen 0 "Screen 0"
Screen 1 "Screen 1" Above "Screen 0"
EndSection

Section "Screen"
Identifier "Screen 0"
Device "Card 0"
EndSection

Section "Screen"
Identifier "Screen 1"
Device "Card 1"
EndSection

Section "Device"
Identifier "Card 0"
Driver "radeon"
BusID "PCI:3:0:0"
EndSection

Section "Device"
Identifier "Card 1"
Driver "radeon"
BusID "PCI:4:0:0"
EndSection
==

I added some monitor sections and not only did it work exactly
as it does with this, I couldn't make it do anything better or
different.

Key parts:
* the BusID lines seem critical.  Otherwise, just get first card.
* a "Screen" appears to be all monitors attached to one Device.
* My primary video card ("Screen 0" is attached to two monitors
on my desk, the secondary video card ("Screen 1") is attached to
two monitors above them.  Hence, the "Screen 1" Above "Screen 0"

I found Fluxbox seems to work with all four monitors as you
described fvwm doing.  The mouse can move appropriately between
all four monitors, but tasks can only go side-to-side in one
"screen" (two monitors).  This, I was actually excited about, as
I wanted to be able to have multiple INDEPENDENT desktops between
monitors. Ok, I got it between PAIRS of monitors.  Doesn't suck.

What DOES suck is some of the apps I wanted on both screens...don't.
Firefox and Chrome both refuse to start a new instance in the other
screen.  Not the end of the world, there are more browsers out there,
I suspect I can run iridium or something similar in one "screen" and
a cousin in the other.

My "screens" are slightly dissimilar -- screen 0 is two 1920x1200 
monitors, screen 1 is two 1920x1080 monitors.  No issues noted.

The login box and the ssh key box are centered between two monitors.
Annoying, but not a show stopper.  In general, while two monitors on
one card seemed to keep track of each monitor (didn't start things 
straddling them), four monitors on two cards...not quite so elegant.

Once running, seems I can use xrandr to rotate and mess with
individual monitors.

So ... It does work!

Nick.


> On Thu, Jun 27, 2019 at 12:38 PM Nick Holland 
>  wrote:
>> 
>> Hiya.
>> 
>> Before I spend a lot of time on what might be impossible, is it 
>> likely I could succeed at getting multiple multi-head video cards 
>> working on OpenBSD (amd64, radeon cards)?
>> 
>> I've got this in the machine: OpenBSD 6.5-current (GENERIC.MP) #2:
>>  Sun Jun  2 00:29:17 MDT 2019 
>> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>>
>>
>>
>> 

>> ppb2 at pci0 dev 3 funct