[lcdproc] dealing with multiple instances with .so
Thu, 29 Mar 2001 16:21:08 +0100 (BST)
Andre Breiler mentioned the following:
| NOTE: in this mail is screen the physical device!
Yeah, you knew what I meant! :)
| On Thu, 29 Mar 2001, Matt wrote:
| > each screen from the libmtxorb.so, it will return an id for that instance,
| > probably just number from 0 or 1 upwards. Therefore we can give each and
| This is something what the lcdd have to count because the libfuntion
| itself doesn't know the numer of instances (the only way is the open
| counter of the lib).
No, each driver can maintain it's own count internally, this isn't a
problem. As each multiple instance of any library will be the same
instance, a simple static counter would suffice. Something more elaborate
might be needed if the situation arose, but the idea is the same.
| > every screen its own id by just combining each driver name with the
| > instance id, we have mtxorb0, mtxorb1, cfontz0, etc.
| > Far more simple IMHO we don't need quite as many config options now.
| Hmm, so if I connect as client can I say I like the screen X and I get
| every time the same screen ?
| I don't think because it depends on the way how we parse the
| config and load/init the drivers.
I thought that the server would supply a more verbose list of displays
available to each client, much more than it does currently. Such that it
might say: "mtxorb0 - Matrix Orbital display, 20x4, connected to
/dev/ttyS1", etc. Such that if a client always wants to connect to the
display hooked on /dev/ttyS1, you can pattern match to get the correct id,
in this case mtxorb0.
| The idea not to use a server supplied ID was that we can use in all parts
| of the system (also for distributed drivers).
| With you approch I have to calculate a different ID (which is
| also unique in the distributed case) in a wrapper for distributed drivers.
| Is also not possible to guess the ID if you don't cant remeber ther order
| of the config sections ...
The one problem with not auto-generating ids, is that you make the client
dependent on the server config, the two should not have to be
co-configured by the same person.
To unsubscribe from this list send a blank message to