> > another layer between the "hotplugging program" and the event
interface,
> > one could later easily rewrite this layer to support other unices.
> Pretty sure that it doesn't. However I just installed FreeBSD last
night,
> and
> therefore qualify as a complete newbie on *BSD.
I can't prove this but I think that I maybe could have heard someday or
anytime that *BSD maybe supports something similar to the Linux Event
Interface. But as you probably hear from my way of express myself I'm
pretty unsure.
>
> > I would propose to write functions like GetCapabilities (...)
instead of
> > using ioctl calls like in the howto you pointed at in an earlier
mail.
> > Rewriting this functions will then later perhaps be the only step
needed
> > to port the application.
> You have to ioctl() to talk to the kernel. /dev/input/eventX is only a
> char
> device, not an RPC mechanism. Of course, the whole point of the
mid-level
> application is to translate the kernel event API into the form
required by
> the user applications.
But I think if one really aims at a portable application (without being
to greedy, which might lead to failure ;) ) it might be possible. Let's
for instance create a library "libevent" which abstracts all calls to
the Event Interface. I'll take another look at the document at
www.frogmouth.net/hid-doco and <linux/input.h> as of 2.5.35 and 2.4.19.
This might make it possible to me to create a library that will abstract
things quite good. Porting this library later, should make life a lot
more easier.
>
> The hotplugging program is likely going to do so many operating system
> dependent things that I'd consider it to be non-portable.
Jepp, perhaps the libevent will be non-portable, but it won't be
non-rewritable (ie. Portable ;) ) for different platforms.
> This is not to say that there can't be a common API to the main
userspace
> applications, like X. In fact, there is no reason why it couldn't talk
> native X events
Why not, you're right, this could make things lot more easier. X is
already a standard.
> (ie the hotplugging application becomes an X input driver), subject to
> being able to exist without X at least part of the time.
Maybe later it could become an X input driver.
> > > You realise that the buttons on USB speakers are identical to the
> > > multimedia keys?
> >
> > I had no clue actually, I'm rather stupid when it comes to USB
stuff,
> > didn't know of any USB speakers actually. I always thought that ALL
> > speakers we're connected to the soundcard with a cinch cable.
> USB speakers are basically a soundcard (that interfaces via USB
instead of
> PCI or ISA), the speakers, and usually a set of buttons - at least
some of
> which are on a HID interface. Speakers are actually optional - see the
> "extigy" by creative.
Oki.
> > > Basically, we need to represent all the Linux input event codes as
X
> > > events, and then somehow associate the right set of controls with
the
> > > right audio device.
You mean for example in the case there are two sets of USB speakers?
> > > Initial design will work on there only being a
> > > single set, while later versions will use the driverfs tree to
show
> > > the combination devices.
> >
> > I'm not so well informed when it comes to driverfs, can you point me
to
> > a good paper on it?
> There isn't too much documentation yet. If you want to _really_ know,
you
> need to follow the linux-kernel mailing list (look for posts from Pat
> Mochel and Greg Kroah-Hartman). An overview (now a bit outdated) is
> provided in Pat Mochel's paper for OLS 2002 (see
.... pssss. Don't disturb, currently reading.
>
> > > I don't think that anyone makes hotplug PCI video. Have to
check....
> >
> > I could really need a hotplug/hotconfig PCI video card. I'm
designing a
> > surveillance center for a client and I'm thinking of just taking a
> > powerful Athlon or something and filling it with a lot of pci cards.
If
> > it would be possible to switch cards while the system is running
(remove
> > broken ones) => this would make it a lot more easier for me to make
the
> > client understand that XFree is the only way to go (they were
initially
> > thinking of Win2k).
> >
> > So I think video HOTPLUG is not too abstract anyway.
> As another poster pointed out, it is really a backplane problem, not a
> card
> problem. You just need to poke the right initialisation bits on the
card.
> Maybe it will just work.
Think I got an old ATI Mach64 from '95 to do hotplug. I connect it
beside my TNT2, the second monitor it always black until I first startup
X, after that it shows some BIOS info even if X is not "online". It
seems to me that the card is uninitialized until first initialized by X.
It could be hotplugging what I'm seeing here, need to investigate more
;)
>
> > I think that the database must differentiate between provided
services
> > and configurations, because (just an idea) I think of an SERVICE
that a
> > device provides as something, that it can always do, AND also
> > simultaneous to other SERVICES. (Let's assume device A provides
services
> > 1 and 2, then the system must be able to use this services
> > simultaneously, like a video card, that can clone displays.)
> >
> > The different between configurations is, that the device cannot have
two
> > active configurations the same time, that means if a card can do
TV-OUT
> > and CRT-OUT but not simultaneously (like my Elsa Erazor III), then
this
> > is considered two configurations.
> >
> > By differentiating between configurations and services, the
> > "autoconfiguration system" knows if it can for example switch on
> > Xinerama for a card with multiple outputs.
> Ah, I see.
> USB has this kind of concept (they are called "alternate settings" and
> "configurations" and "interfaces" - the spec is horrible :)
> At a database level, you maybe want to do something like:
> SERVICE is a particular capability or setting (eg 640x480 on a CRT or
525-
> line
> video on a TV)
> CAPABILITY is a set of simultaneous services.
>
> This can handle the problem where "yeah, it is dual head, but you can
only
> do
> 1960x1240 if you have the other output disabled".
>
> Any modern card is going to have a lot of capabilities - if you have M
> options
> on the analog connector and N options on the digital connector, then
there
> are potentially MxN combinations. But that probably isn't a real
problem
> for
> a database.
>
I'll have to take a closer look at this one ;) Now I'll have to visit a
beautiful girl first, but by then I'll come back with hopefully ;) some
good ideas :)
> > > > - hints for software that can use the device
> > > > (in case of DVD-ENCODER card, that could be xine with
dvdnav
> > > > patches)
> > >
> > > Perhaps a class of software?
> >
> > Good idea, it would really be stupid to only point to special
> > applications, but I thought of some way for distributions
maintainers to
> > put in links to packages in here. This would enable systems like
apt-get
> > to present a list of different packages that can be used with
different
> > hardware.
> This is what a relational database is for. The software table just has
> entries
> for application to interface, and the driver table just has device to
> interface. So if you want to know what applications can work - just do
an
> inner join (?) on the two tables.
>
I were just wondering a second ago if a SQL would be well-suited for
this. But I don't think so, because one might need a solution that can
be shipped on a CD for example and I don't know if one can use a SQL-DB
without having to start a server.
I'm way too unprofessional to be using SQL I think. A month ago I didn't
even know that SQL stands for "Squirrel Lobby" which is the main
consortium providing SQL standards.
>
> > > > - device can only work if service FOO is provided by
another
> > > > device
> > >
> > > Not sure if I understand this. Can you provide a canonical
example?
> >
> > A 3D-only card (providing service 3DGRAPHICS) can only work if
another
> > 2D-card is installed (providing service GRAPHICS). This is the case
with
> > Voodoo1 cards for example. I know that the Voodoo cards are very old
and
> > not supported well. But the scenario existed for the Voodoo card,
what
> > says it cannot appear again with other hardware (for example the new
> > Nvidia n500 card, providing 4D graphics must be combined with a 3D
card
> OK. I was thinking of devices where the two cards are always paired,
which
> can be recast as a single logical device with two PCI IDs.
>
> This whole database problem is vaguely similar to the way foomatic
handles
> printers. Maybe you could leverage some of that work?
>
I'll take a look at that project.
> > > > I have not got through the phase where I have to define some
generic
> > > > structure about every device, and I'm not sure how to define
> > > > setup-strategics for each device (perhaps a script that adds a
> > > > specific section to the XF86Config, or just let the distribution
> > > > parse the info and decide on it's own).
> > >
> > > This bit about "adds a specific section to the XF86Config" is the
> > > problem I am interested in solving. I don't want to have to
restart�
> > > the X server - that isn't hotplugging. I want to change the server
> > > configuration on-the-fly.
> >
> > > So when I add a USB mouse, the kernel hotplug mechanism will exec
a
> > > script, and this will load the input-event driver into the X
server,
> > > and then kick the server to recognise the new device. The X server
> > > will then probe (or read from a database) the device capabilities
and
> > > the device topology. The events from the mouse will then be
connected
> > > to the right X event stream, and X will inform running
applications of
> > > any new capabilities.
> > >
Why not have these steps:
1) receive funny hotplug event from event interface
2) create new configuration from funny event information
3) PROPOSE funny new configuration to X
a) X accepts, goto (4)
b) X denies, die ("ERROR!");
4) kick X to take over funny new configuration
(excuse me for having put 'funny' all over here, I'm just being in a
funny mood)
> > > The only problem is that I have no idea how to make X do this.
> >
> > Perhaps anybody in this list can inform us if there is an existing
> > EXTENSION for this. Otherwise, we'll have to write one ;) that can't
be
> > too hard *laughs*.
> AFAICT, X 4 is based around the concept of loadable modules. Clearly
it
> works really well at start-time. I am just not sure of how well it
will
> work when the X server is already running.
The loadable module thing works so fine for me that I have never ever
configurated X!! It just started without problems from the very
beginning ;). It probed everything correctly, from graphics driver to
LCD caps...Tadaaa!
>
> > But I don't think that we'll have to inform running applications. If
the
> > newly (hotplugged) mouse has a wheel, the X server will begin
sending
> > special events when the new mouse is connected. The applications
will
> > take care of them, or they won't.
> I am thinking about applications like a CAD application, which might
> reconfigure itself to use a 6 degree of freedom device like a
spaceball,
> but does different things if you add a tablet.
>
The question is, can X do this? Is there a way for X to tell running
applications that the Server Layout and/or configuration has changed?
It'll be hell on earth for us if not...
Mikael
[EMAIL PROTECTED]
> Or a game that starts sending force-feedback events if the attached
device
> supports force-feedback. The events may well change depending on the
> capabilities of the device.
>
> Brad
> - --
> http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in
Black.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iD8DBQE9hnl/W6pHgIdAuOMRAulYAJ0aILgGUhy9zatmoTtZMtH+Ots4ggCgw2h8
> wGAmBlHpGBWU/t48Gatmnyg=
> =9lIN
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Xpert mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/xpert
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
