Re: [AD] Hotplug joysticks

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On August 18, 2010, Peter Wang wrote:
> On 2010-08-18, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> wrote:
> > On August 18, 2010, Peter Wang wrote:
> > > On 2010-08-18, Trent Gamblin <trent@xxxxxxxxxx> wrote:
> > > > I've got joystick hotplugging working on Windows right now.
> > > > This is one feature that maybe should be added to 4.9 now
> > > > because it changes the semantics of how things work a bit.
> > > > This is how it works:
> > > > 
> > > > The user installs joystick driver and calls al_get_num_joysticks
> > > > and al_get_joystick(x). Everything behaves as normal until:
> > > > The (new) system event source (al_get_system_event_source) emits a
> > > > ALLEGRO_EVENT_JOYSTICK_CONFIGURED event.
> > > 
> > > I would prefer a dedicated joystick subsystem event source. 
> > > Actually, we don't *need* a separate joystick event source per
> > > joystick, so maybe we should use a single joystick event source for
> > > all joysticks. In fact, the user doesn't need to see
> > > ALLEGRO_JOYSTICK objects at all: just use the joystick number.  In
> > > many ways this would be more convenient.
> > 
> > Thats what I thought too, but a user may want to have a separate thread
> > per display, and give the joystick to that thread as well. Unless this
> > joystick number can be used to register a given joystick in a separate
> > queue?
> 
> No.  I can't see it being an important case to cater to, though.
> 
> > > > At this point, the user can ignore the event and proceed as
> > > > normal, but if they call al_get_num_joysticks, the present "user"
> > > > configuration of sticks changed to the present "system" view of
> > > > joysticks (what is actually plugged in and not on the system at
> > > > that time.) User calls al_get_joystick(x) again for all desired
> > > > joysticks.
> > > 
> > > How about adding al_reinstall_joystick(), or
> > > al_reconfigure_joysticks()? It would then be obvious that from that
> > > point, al_get_num_joysticks may change, all old joystick structures
> > > become invalid (if that's what we want), and they need to be
> > > reregistered (unless we switch to a single joystick event source).
> 
> Another good thing is that this would support platforms without hotplug
> notifications.  You could call al_reinstall_joystick() when the user
> enters the "Controls" section of your game's menu, which could be more
> efficient than al_uninstall_joystick + al_install_joystick.
> 
> > I think it'd be better to just automatically de-register joysticks on
> > removal. In most cases all it means is the joystick events stop coming.
> > if you're doing anything clever with the ALLEGRO_JOYSTICK structures
> > you're asking for trouble. Though theres no need to free those
> > structures either, unless the joystick subsystem stores them in an
> > array for some reason. But either way there really isn't a need to do
> > anything special with them.
> 
> I don't think it makes much difference if you unregister automatically,
> except that the events which were waiting in queues would be removed.
> 
> 
> Am I right that al_get_num_joysticks() will mean "max joystick number"
> or "number of potential joysticks" (which it sort of does already)?
> If you remove a joystick, the other joysticks ought to retain their
> numbers, so there will be unused slots between between 0 ..
> al_get_num_joysticks()-1.

My original suggestion to trentg involved joysticks having a unique id so a 
joystick once plugged in never has its number changed. and while you could 
use a get_num_joysticks, and get_joystick(idx) interface, you wouldn't use 
those 0-N indexes anywhere else, as they may not match the joystick's actual 
id.

Or something I just came up with, a findfirst/next like api for joysticks. 
Instead of a get_num,get_joystick(id) api. then it doesn't matter how many 
there are, or what the ids mean. it will only return existing joysticks, and 
noone has to worry about empty spaces.

But if you like unused slots, thats an option too.

> Peter
> 
> -------------------------------------------------------------------------
> ----- This SF.net email is sponsored by
> 
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev


-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/