From mint-bounce@lists.fishpool.fi Sun Apr 3 01:57:22 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Subject: [MiNT] Multimedia Keys & Notification From: "Evan K. Langlois" To: mint@fishpool.com Content-Type: multipart/alternative; boundary="=-/SS18AV9RiKreVWe6gfb" Organization: Cool Running Concepts Date: Sat, 02 Apr 2005 17:53:36 -0600 Message-Id: <1112486017.28763.205.camel@taro.coolrunningconcepts.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc14.midphase.com X-AntiAbuse: Original Domain - fishpool.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - CoolRunningConcepts.com X-Source: X-Source-Args: X-Source-Dir: X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: Evan@CoolRunningConcepts.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=-0.9 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00, HTML_MESSAGE X-Spam-Level: --=-/SS18AV9RiKreVWe6gfb Content-Type: text/plain Content-Transfer-Encoding: 7bit I would like to make a proposal. There has been a lot of talk about multimedia keys recently, and I would like to make a suggestion for the addition of a new message. This new message would be sent to the application when a multimedia key is pressed on a multimedia enabled keyboard, a remote control (if you have an IR remote driver), or another application. An application would send this to separate the API from the actual application that renders the media (audio or video), allowing a separation of APIs and allowing the user to use whichever front-end they prefer. Also, maximum flexibility and interoperability for future and unforeseeable usages should be maximized. The messages would be the same type of messages you would get via evnt_mesag() with a new message type, maybe AP_MEDIA (don't care about the name of the #define). No scan-codes (since multimedia keys are normally a sequence of codes that the application would have difficulty interpreting) or any other keyboard-dependent information would need to be sent to the user application. The OS should abstract this information for the programmer. Application events would be sent to the top-most application that is waiting on multimedia events - indicated via a new EVENT flag to evnt_multi() or a new wind_set() flag. I like the wind_set() flag idea better. Examples of Global multimedia messages might be the Web Browser, Lock Screen, Email, Full-Screen, Maximize, or Application-Switch keys on a multimedia keyboard, or "TV" button on an IR Remote. It should be possible for applications to generate these to launch your "preferred" application and generate these events for special purposes (perhaps a special application switcher with fancy special effects, etc - the switch-app-key would execute an app which would perform some animation and generate the switch-app-action to finish it, details on how sending the multimedia-key-events and the multimedia-actions they can be mapped to, are open to speculation and discussion). Examples of Application specific keys would be Play, Pause, Next Track, Skip to Track ##, Eject, double-size, and things of that sort. Some events would be sent to the application only if there was an application waiting to receive multimedia events, and could be handled by the OS itself otherwise, for example, Volume Up, Volume Down, and MUTE could be handled by adjusting the master volume and mute of the sound system independently of any applications. Likewise Eject could open the first CD-ROM drive if no application wanted multimedia events. Applications could even resend the message back to the OS to have the OS do whatever the mapped global event should be (this won't loop). In this scheme, the device drivers would report the events to the AES (this part needs further development) which would dispatch the event accordingly depending on the type of event, if any applications were waiting on multimedia events, and finally, the control panel for global events. There would be two classes of events, global events, and application events. Global events would perform an action, such as switching windows, iconifying the top window, or executing a program. The exact action would be configured through a control panel or CPX and the OS (or maybe the Desktop or the CPX) would handle this itself. I was also considering a new signal, which would be ignored if the application didn't have a handler for it, which would tell the application that a new AES message was waiting for it, sort of an AIO type of thing. I freely admit this idea is a sub-optimal HACK, but would work, and in some situations, better than kqueue() - like if you need constant processing and event handling is completely secondary and you don't want to make OS calls to look for events. This was one of my suggestions years ago when I was looking for a solution to unify the event loop, but the non-multitasking ROM-AES made this problematic. The signal would break the program out of select() or any other call, and you could check a variable, that the signal handler would modify, to see if you needed to read a new message via appl_read(). Since you can't tell the AES what events you want, another thread or process would call evnt_multi() if you needed those events and send the data to you via appl_write(). Otherwise, you only need to look at AES messages when told. This would work even for applications that were busy processing audio (like an mp3 player) in a tight loop and didn't otherwise need event processing and the overhead of calling evnt_multi() or other OS calls constantly, since the entire GUI interface could be implemented in a separate process that simply sent messages to the application. This could remove a lot of polling for applications that really need constant processing and separate threads instead of an event loop. Its less ideal if there are constant AES events, but this scheme could work for things like TOSWIN as well. No front-end need show at all if you have a multimedia keyboard or IR remote and the above extensions as front-ends could be completely separate from the actual player, or simply enhanced with additional multimedia keys/remote/messages from other applications such as your IRC client, web browser, etc. All comments welcome. Thanks, Evan --=-/SS18AV9RiKreVWe6gfb Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I would like to make a proposal. 

There has been a lot of talk about multimedia keys recently, and I would li= ke to make a suggestion for the addition of a new message.  This new m= essage would be sent to the application when a multimedia key is pressed on= a multimedia enabled keyboard, a remote control (if you have an IR remote = driver), or another application.  An application would send this to se= parate the API from the actual application that renders the media (audio or= video), allowing a separation of APIs and allowing the user to use whichev= er front-end they prefer.  Also, maximum flexibility and interoperabil= ity for future and unforeseeable usages should be maximized.

The messages would be the same type of messages you would get via evnt_mesa= g() with a new message type, maybe AP_MEDIA (don't care about the name of t= he #define).  No scan-codes (since multimedia keys are normally a sequ= ence of codes that the application would have difficulty interpreting) or a= ny other keyboard-dependent information would need to be sent to the user a= pplication.  The OS should abstract this information for the programme= r.  Application events would be sent to the top-most application that = is waiting on multimedia events - indicated via a new EVENT flag to evnt_mu= lti() or a new wind_set() flag.  I like the wind_set() flag idea bette= r.

Examples of Global multimedia messages might be the Web Browser, Lock Scree= n, Email, Full-Screen, Maximize, or Application-Switch keys on a multimedia= keyboard, or "TV" button on an IR Remote.  It should be pos= sible for applications to generate these to launch your "preferred&quo= t; application and generate these events for special purposes (perhaps a sp= ecial application switcher with fancy special effects, etc - the switch-app= -key would execute an app which would perform some animation and generate t= he switch-app-action to finish it, details on how sending the multimedia-ke= y-events and the multimedia-actions they can be mapped to, are open to spec= ulation and discussion).

Examples of Application specific keys would be Play, Pause, Next Track, Ski= p to Track ##, Eject, double-size, and things of that sort.

Some events would be sent to the application only if there was an applicati= on waiting to receive multimedia events, and could be handled by the OS its= elf otherwise, for example, Volume Up, Volume Down, and MUTE could be handl= ed by adjusting the master volume and mute of the sound system independentl= y of any applications.  Likewise Eject could open the first CD-ROM dri= ve if no application wanted multimedia events.  Applications could eve= n resend the message back to the OS to have the OS do whatever the mapped g= lobal event should be (this won't loop).

In this scheme, the device drivers would report the events to the AES (this= part needs further development) which would dispatch the event accordingly= depending on the type of event, if any applications were waiting on multim= edia events, and finally, the control panel for global events.  There = would be two classes of events, global events, and application events. = ; Global events would perform an action, such as switching windows, iconify= ing the top window, or executing a program.  The exact action would be= configured through a control panel or CPX and the OS (or maybe the Desktop= or the CPX) would handle this itself. 

I was also considering a new signal, which would be ignored if the applicat= ion didn't have a handler for it, which would tell the application that a n= ew AES message was waiting for it, sort of an AIO type of thing.  I fr= eely admit this idea is a sub-optimal HACK, but would work, and in some sit= uations, better than kqueue() - like if you need constant processing and ev= ent handling is completely secondary and you don't want to make OS calls to= look for events.  This was one of my suggestions years ago when I was= looking for a solution to unify the event loop, but the non-multitasking R= OM-AES made this problematic. 

The signal would break the program out of select() or any other call, and y= ou could check a variable, that the signal handler would modify, to see if = you needed to read a new message via appl_read().  Since you can't tel= l the AES what events you want, another thread or process would call evnt_m= ulti() if you needed those events and send the data to you via appl_write()= .  Otherwise, you only need to look at AES messages when told.  T= his would work even for applications that were busy processing audio (like = an mp3 player) in a tight loop and didn't otherwise need event processing a= nd the overhead of calling evnt_multi() or other OS calls constantly, since= the entire GUI interface could be implemented in a separate process that s= imply sent messages to the application.  This could remove a lot of po= lling for applications that really need constant processing and separate th= reads instead of an event loop.  Its less ideal if there are constant = AES events, but this scheme could work for things like TOSWIN as well.

No front-end need show at all if you have a multimedia keyboard or IR remot= e and the above extensions as front-ends could be completely separate from = the actual player, or simply enhanced with additional multimedia keys/remot= e/messages from other applications such as your IRC client, web browser, et= c.

All comments welcome.

Thanks,
Evan





--=-/SS18AV9RiKreVWe6gfb--