USB mouse support vs. devu-uhci

I’m preparing to do some driver development for
a USB joystick. A few questions:

First, is anybody doing this already? I don’t want
to duplicate work.

Second, when I start devu-uhci, Photon loses the USB mouse.

I’m running QNX 6.21, with a USB mouse. That works fine
with no modifications, although I’m not clear on how QNX
is supporting it. At startup, /dev/usb is not created.

If I manually start devu-uhci, it starts properly,
creates /dev/usb, and the “usb” program will inventory
the USB bus and report the presence of the mouse. But
the USB mouse is no longer in communication with Photon
at that point, and moving the mouse has no visible effect.

What’s proper procedure here?

John Nagle

John Nagle <nagle@overbot.com> wrote in message
news:402C6BEB.1020207@overbot.com

I’m preparing to do some driver development for
a USB joystick. A few questions:

First, is anybody doing this already? I don’t want
to duplicate work.

The Mouse driver should be pretty close to what you need.

Second, when I start devu-uhci, Photon loses the USB mouse.

I’m running QNX 6.21, with a USB mouse. That works fine
with no modifications, although I’m not clear on how QNX
is supporting it. At startup, /dev/usb is not created.

If I manually start devu-uhci, it starts properly,
creates /dev/usb, and the “usb” program will inventory
the USB bus and report the presence of the mouse. But
the USB mouse is no longer in communication with Photon
at that point, and moving the mouse has no visible effect.

This is because the Mouse is being emulated as a PS2 mouse
when the USB driver isn’t running. When you start the driver
it takes control of the UHCI chip and your mouse stops working.

You need to start the USB drivers before Photon comes up
and start devi-hirun with the msoft fd -d/dev/usbmouse options.

Search the Knowledge database for usb. I think there is something
there about where to to start the drivers to get this to work properly.

What’s proper procedure here?

John Nagle

Henry VanDyke wrote:

John Nagle <> nagle@overbot.com> > wrote in message
news:> 402C6BEB.1020207@overbot.com> …

I’m preparing to do some driver development for
a USB joystick. A few questions:

First, is anybody doing this already? I don’t want
to duplicate work.


The Mouse driver should be pretty close to what you need.

OK, thanks.

Second, when I start devu-uhci, Photon loses the USB mouse.

This is because the Mouse is being emulated as a PS2 mouse
when the USB driver isn’t running. When you start the driver
it takes control of the UHCI chip and your mouse stops working.

You need to start the USB drivers before Photon comes up
and start devi-hirun with the msoft fd -d/dev/usbmouse options.

Search the Knowledge database for usb. I think there is something
there about where to to start the drivers to get this to work properly.

Oh, another one of those l33t things.

There’s a relevant knowledge base article at

http://www.qnx.com/support/sd_bok/solution.qnx?10411

but it’s for QNX 6.1, and may need an update.

Does this get better in the upcoming release? We can wait.

John Nagle
Team Overbot

My point about it being “another one of those l33t things” is
that if USB support really worked, I’d expect it to be in the standard
traplist and be brought up on normal boots. Since it’s not, does
that indicate that it is not reliable enough for routine use?
Should we wait for the upcoming QNX release?

John Nagle
Team Overbot

John Nagle wrote:

Henry VanDyke wrote
Search the Knowledge database for usb. I think there is something
there about where to to start the drivers to get this to work properly.


Oh, another one of those l33t things.

There’s a relevant knowledge base article at
http://www.qnx.com/support/sd_bok/solution.qnx?10411

but it’s for QNX 6.1, and may need an update.

Does this get better in the upcoming release? We can wait.

John Nagle
Team Overbot

The documentation states that when you start the usb driver and use
devi-hirun, you no longer have access to the mouse in text mode –
photon only.

John Nagle wrote:

My point about it being “another one of those l33t things” is
that if USB support really worked, I’d expect it to be in the standard
traplist and be brought up on normal boots. Since it’s not, does
that indicate that it is not reliable enough for routine use?
Should we wait for the upcoming QNX release?

John Nagle
Team Overbot

John Nagle wrote:

Henry VanDyke wrote

Search the Knowledge database for usb. I think there is something
there about where to to start the drivers to get this to work properly.



Oh, another one of those l33t things.

There’s a relevant knowledge base article at
http://www.qnx.com/support/sd_bok/solution.qnx?10411

but it’s for QNX 6.1, and may need an update.

Does this get better in the upcoming release? We can wait.

John Nagle
Team Overbot

John Nagle wrote:

My point about it being “another one of those l33t things” is
that if USB support really worked, I’d expect it to be in the standard
traplist and be brought up on normal boots. Since it’s not, does
that indicate that it is not reliable enough for routine use?
Should we wait for the upcoming QNX release?

I think it is more an indication that nobody has written an enum-usb, than
it is an indication that the actual driver is not reliable. Also, devi-*
needs to be re-written so that it accepts mounts/umounts (or something
similar) so that input drivers can come and go…

Rennie Allen <rallen@csical.com> wrote in message
news:c0rhv1$hgl$1@inn.qnx.com

John Nagle wrote:
My point about it being “another one of those l33t things” is
that if USB support really worked, I’d expect it to be in the standard
traplist and be brought up on normal boots. Since it’s not, does
that indicate that it is not reliable enough for routine use?
Should we wait for the upcoming QNX release?

I think it is more an indication that nobody has written an enum-usb, than
it is an indication that the actual driver is not reliable. Also, devi-*
needs to be re-written so that it accepts mounts/umounts (or something
similar) so that input drivers can come and go…

There is io-hid, devi-hid which does this.

I guess startup(devc-con) is the main issue that needs to be addressed.
Devc-con
needs to be changed to talk to io-hid which in turn talks to the USB stack.
In the current
release the console driver accesses hardware directly. This is why you cant
switch between
Photon and a text console while using a USB keyboard.

OK, that identifies the problem clearly. Will this
be fixed in the upcoming QNX release? Thanks.

John Nagle
Team Overbot

Henry VanDyke wrote:

Rennie Allen <> rallen@csical.com> > wrote in message
news:c0rhv1$hgl$> 1@inn.qnx.com> …

John Nagle wrote:

My point about it being “another one of those l33t things” is
that if USB support really worked, I’d expect it to be in the standard
traplist and be brought up on normal boots. Since it’s not, does
that indicate that it is not reliable enough for routine use?
Should we wait for the upcoming QNX release?

I think it is more an indication that nobody has written an enum-usb, than
it is an indication that the actual driver is not reliable. Also, devi-*
needs to be re-written so that it accepts mounts/umounts (or something
similar) so that input drivers can come and go…


There is io-hid, devi-hid which does this.

I guess startup(devc-con) is the main issue that needs to be addressed.
Devc-con
needs to be changed to talk to io-hid which in turn talks to the USB stack.
In the current
release the console driver accesses hardware directly. This is why you cant
switch between
Photon and a text console while using a USB keyboard.
\

John Nagle <nagle@downside.com> wrote in message
news:c0th92$8hd$1@inn.qnx.com

OK, that identifies the problem clearly. Will this
be fixed in the upcoming QNX release? Thanks.

It will be resolved in “an” upcoming release. Probably not “the” upcoming
release though :sunglasses:

Henry

John Nagle
Team Overbot

Henry VanDyke wrote:
Rennie Allen <> rallen@csical.com> > wrote in message
news:c0rhv1$hgl$> 1@inn.qnx.com> …

John Nagle wrote:

My point about it being “another one of those l33t things” is
that if USB support really worked, I’d expect it to be in the standard
traplist and be brought up on normal boots. Since it’s not, does
that indicate that it is not reliable enough for routine use?
Should we wait for the upcoming QNX release?

I think it is more an indication that nobody has written an enum-usb,
than
it is an indication that the actual driver is not reliable. Also,
devi-*
needs to be re-written so that it accepts mounts/umounts (or something
similar) so that input drivers can come and go…


There is io-hid, devi-hid which does this.

I guess startup(devc-con) is the main issue that needs to be addressed.
Devc-con
needs to be changed to talk to io-hid which in turn talks to the USB
stack.
In the current
release the console driver accesses hardware directly. This is why you
cant
switch between
Photon and a text console while using a USB keyboard.

\

A little more effort on supporting modern PCs out of the
box would be appreciated. The supported hardware list has
become so retro that it’s hard to buy QNX desktop machines.

Most modern machines are coming with Ethernet, USB, and
a display controller built into the motherboard chipset.
Typically the chipset is from Via or Intel. (I know that
NVidia won’t cooperate with QSSL). In many cases, QNX
has the drivers to support these peripherals, but the
traplist and drivers don’t know the appropriate PCI
device IDs. This is not good.

My own pet peeve is the VIA implemention of the Savage
display controller. QNX supports older Savage controllers,
and Via is putting a newer implementation into many chipsets,
but QNX won’t run the newer implementation, other than in
slow VESA mode.

Remember when the QNX boot disk just worked? That
was impressive. It’s also history.

John Nagle

Henry VanDyke wrote:

John Nagle <> nagle@downside.com> > wrote in message
news:c0th92$8hd$> 1@inn.qnx.com> …

OK, that identifies the problem clearly. Will this
be fixed in the upcoming QNX release? Thanks.


It will be resolved in “an” upcoming release. Probably not “the” upcoming
release though > :sunglasses:

Henry

John Nagle
Team Overbot

Henry VanDyke wrote:

Rennie Allen <> rallen@csical.com> > wrote in message
news:c0rhv1$hgl$> 1@inn.qnx.com> …


John Nagle wrote:


My point about it being “another one of those l33t things” is
that if USB support really worked, I’d expect it to be in the standard
traplist and be brought up on normal boots. Since it’s not, does
that indicate that it is not reliable enough for routine use?
Should we wait for the upcoming QNX release?

I think it is more an indication that nobody has written an enum-usb,

than

it is an indication that the actual driver is not reliable. Also,

devi-*

needs to be re-written so that it accepts mounts/umounts (or something
similar) so that input drivers can come and go…


There is io-hid, devi-hid which does this.

I guess startup(devc-con) is the main issue that needs to be addressed.
Devc-con
needs to be changed to talk to io-hid which in turn talks to the USB

stack.

In the current
release the console driver accesses hardware directly. This is why you

cant

switch between
Photon and a text console while using a USB keyboard.



\

It must be in light of this situation that QNX has apparently decided to
discontinue support for SB Live!
Who wants antiquated hardware anyway, right? :wink:

“John Nagle” <nagle@downside.com> wrote in message
news:c184me$gfg$1@inn.qnx.com

A little more effort on supporting modern PCs out of the
box would be appreciated. The supported hardware list has
become so retro that it’s hard to buy QNX desktop machines.

Most modern machines are coming with Ethernet, USB, and
a display controller built into the motherboard chipset.
Typically the chipset is from Via or Intel. (I know that
NVidia won’t cooperate with QSSL). In many cases, QNX
has the drivers to support these peripherals, but the
traplist and drivers don’t know the appropriate PCI
device IDs. This is not good.

My own pet peeve is the VIA implemention of the Savage
display controller. QNX supports older Savage controllers,
and Via is putting a newer implementation into many chipsets,
but QNX won’t run the newer implementation, other than in
slow VESA mode.

Remember when the QNX boot disk just worked? That
was impressive. It’s also history.

John Nagle

Henry VanDyke wrote:
John Nagle <> nagle@downside.com> > wrote in message
news:c0th92$8hd$> 1@inn.qnx.com> …

OK, that identifies the problem clearly. Will this
be fixed in the upcoming QNX release? Thanks.


It will be resolved in “an” upcoming release. Probably not “the”
upcoming
release though > :sunglasses:

Henry

John Nagle
Team Overbot

Henry VanDyke wrote:

Rennie Allen <> rallen@csical.com> > wrote in message
news:c0rhv1$hgl$> 1@inn.qnx.com> …


John Nagle wrote:


My point about it being “another one of those l33t things” is
that if USB support really worked, I’d expect it to be in the
standard
traplist and be brought up on normal boots. Since it’s not, does
that indicate that it is not reliable enough for routine use?
Should we wait for the upcoming QNX release?

I think it is more an indication that nobody has written an enum-usb,

than

it is an indication that the actual driver is not reliable. Also,

devi-*

needs to be re-written so that it accepts mounts/umounts (or something
similar) so that input drivers can come and go…


There is io-hid, devi-hid which does this.

I guess startup(devc-con) is the main issue that needs to be addressed.
Devc-con
needs to be changed to talk to io-hid which in turn talks to the USB

stack.

In the current
release the console driver accesses hardware directly. This is why you

cant

switch between
Photon and a text console while using a USB keyboard.




\

Igor Kovalenko <kovalenko@attbi.com> wrote:
IK > It must be in light of this situation that QNX has apparently decided to
IK > discontinue support for SB Live!
IK > Who wants antiquated hardware anyway, right? :wink:

QNX has made commitments to the embedded world. They figure that system
designers can just pick and choose what hardware they want to integrate
into their system.

QNX hasn’t made any attempts to be a desktop OS for the better part of
a decade now.

Bill Caroselli wrote:

QNX hasn’t made any attempts to be a desktop OS for the better part of
a decade now.

Then why all the work on multimedia support? New browsers?
ABIWord? Those are all desktop OS features.

Besides, it’s good to run self-hosted and eat your own
food. That way you find out what doesn’t work while in a more
forgiving environment.

John Nagle
Animats

John Nagle <nagle@downside.com> wrote:
JN > Bill Caroselli wrote:

QNX hasn’t made any attempts to be a desktop OS for the better part of
a decade now.

JN > Then why all the work on multimedia support? New browsers?
JN > ABIWord? Those are all desktop OS features.

JN > Besides, it’s good to run self-hosted and eat your own
JN > food. That way you find out what doesn’t work while in a more
JN > forgiving environment.

I agree. And I do do self-hosted development. I’m just saying that
QNX is not as friendly a development environment as it was in the QNX4
hay-day.

John Nagle <nagle@downside.com> wrote:
JN > Bill Caroselli wrote:

QNX hasn’t made any attempts to be a desktop OS for the better part of
a decade now.

JN > Then why all the work on multimedia support? New browsers?
JN > ABIWord? Those are all desktop OS features.

Also, these are being developed as consumer electronics features.
Again, not desk-top.

It’s a better desktop system than QNX 4, though, because it’s more
POSIX-compliant and because there’s so much free software out
there that will run on QNX.

The big problem is that typically QNX gets about 90% of the
way to being usable on the desktop in key areas, but not
100%. Often the drivers are there, but not properly configured
to work out of the box. It’s so frustrating.

If QSSL could figure out some way to get a volunteer effort
going amongst the NC users to fix some of these problems, that
would be a step forward. It’s in QSSL’s interest that there
be many NC users, to keep the visibility of QNX up.
It’s essential that key open source software that
QNX uses (GNU, Eclipse, etc.) work on QNX. In too many
cases, the development teams for major open source packages
don’t build for QNX as a standard target. GCC, Eclipse,
and ffmpeg are all part of standard, and important, QNX tools. But
try downloading the source for any of them and building
it on QNX. It won’t be fun.


John Nagle
Team Overbot

Bill Caroselli wrote:

John Nagle <> nagle@downside.com> > wrote:
JN > Bill Caroselli wrote:

QNX hasn’t made any attempts to be a desktop OS for the better part of
a decade now.


JN > Then why all the work on multimedia support? New browsers?
JN > ABIWord? Those are all desktop OS features.

JN > Besides, it’s good to run self-hosted and eat your own
JN > food. That way you find out what doesn’t work while in a more
JN > forgiving environment.

I agree. And I do do self-hosted development. I’m just saying that
QNX is not as friendly a development environment as it was in the QNX4
hay-day.

Bill Caroselli wrote:

Also, these are being developed as consumer electronics features.
Again, not desk-top.

AbiWord is a consumer electronics feature ? Can’t wait to get AbiWord
on my cell phone… (on second thought, I might be able to survive a
while without it :slight_smile: