When the standard keyboard key to increase the volume is hit on windows, a small window appears in the upper left displaying the volume and possibly information about playing media. I am looking for a way to trigger the window without changing the volume status, preferably in an easy to integrate way with Autohotkey.
Windows 8 introduced the MediaControl class that lets Modern apps hook into the system playback control. In Windows 8.1 and 10 it was replaced by the SystemMediaTransportControls class.
While it supports "Manual control of the System Media Transport Controls" there does not seem to be a way to show/hide the overlay and certainly not from a desktop app.
Going into undocumented territory I found the class name of the overlay and that lead me to HideVolumeOSD. Unfortunately the class names are rather generic so you probably have to look at the size of the window as well to determine if it is the volume overlay.
I don't know if just showing the window will work, Windows is not expecting it to be visible except in response to keyboard and playback events. The HideVolumeOSD app uses keybd_event (volume up/down) to trigger it but this is problematic as noted in the comments...
I set up an autohotkey to send volume up, the volume down (For shortcut ctrl+pgdn).
^PgDn::
Send {Volume_Up}
Send {Volume_Down}
return
The desired behavior when used with volume control keys can be gotten by storing the current volume, sending a media key press, then updating the volume to the stored value +/- 1 (or +0, if just seeking to display the OSD).
There is an edge case when mimicking Volume_Down when the volume is <=3. The sent Volume_Down keypress triggers the mute, but this can be accommodated for by manually setting the mute to be off afterwards, or by pre-setting the volume to 4, which prevents the rounding to 0. Which method to choose depends upon if you prefer a brief blip of potentially louder sound (pre-set to 4) or a brief mute (disable mute afterwards) when the volume is lowered from <=3 values.
The following code is in AHK v2.
; Prefix with '$' so as to prevent self triggering, since internally sending Volume_Up
$Volume_Up::{
; Get the current volume. SoundGetVolume returns a float which often needs rounding
volume:=Round(SoundGetVolume())
; Send the Volume_Up key, so the media display is triggered
Send "{Volume_Up}"
; Indiscriminately set the volume manually to volume+1
SoundSetVolume(volume+1)
}
; Much the same as above, yet when sending Volume_Down at volumes <=3 the volume
; is rounded down to 0 which triggers mute. The volume is then set properly,
; yet remains muted. In order to not hear a cut in the audio, you need to set
; the volume to 4 when (1<volume<=3) so that the Volume_Down doesn't round it
; down to 0, or disable the mute afterwards (if volume > 1). This causes a
; brief volume spike or mute blip, respectively. Currently the volume spike option
; is uncommented.
$Volume_Down::{
volume:=Round(SoundGetVolume())
; Bumping the volume before sending the Volume_Down to prevent mute blip (if needed)
if(1 < volume and volume <= 3){
SoundSetVolume(4)
}
Send "{Volume_Down}"
SoundSetVolume(volume-1)
; ; Disable accidental triggering of mute when volume >= 3 after sending Volume_Down
; if(volume > 1) {
; SoundSetMute(0)
; }
}
To just trigger the OSD as the question asks the following works. Hitting a volume key then quickly resetting the volume will displays it, yet considerations need to be made if currently muted as to prevent a blip of sound. Volume keys are used since double toggling Volume_Mute causes a gap in the sound output.
; Trigger the on screen display of the volume bar by hitting Volume_Up and
; then quickly resetting the volume. If muted and send Volume_Up, we will
; hear audio at original volume for a brief second. To prevent this, we
; can set the volume to 0 and send Volume_Down instead.
^PgUp::{
volume:=Round(SoundGetVolume())
muted:=SoundGetMute()
; Trigger the display with a volume key (might briefly bump the volume if unmuted)
if (muted or volume == 0) {
SoundSetVolume(0)
Send "{Volume_Down}"
} else {
Send "{Volume_Up}"
}
; Reset to the original volume and mute status
SoundSetMute(muted)
SoundSetVolume(volume)
}
All of the same code, yet uncommented:
$Volume_Up::{
volume:=Round(SoundGetVolume())
Send "{Volume_Up}"
SoundSetVolume(volume+1)
}
$Volume_Down::{
volume:=Round(SoundGetVolume())
if(1 < volume and volume <= 3){
SoundSetVolume(4)
}
Send "{Volume_Down}"
SoundSetVolume(volume-1)
}
^PgUp::{
volume:=Round(SoundGetVolume())
muted:=SoundGetMute()
if (muted or volume == 0) {
SoundSetVolume(0)
Send "{Volume_Down}"
} else {
Send "{Volume_Up}"
}
SoundSetMute(muted)
SoundSetVolume(volume)
}
Building on Anna Wang's answer (https://stackoverflow.com/a/62012058/3251466).
This will restore the volume even when it was at an odd value.
^PgDn:: ;Ctrl+Page Down
SoundGet, original_volume
SendInput {Volume_Down}
SoundSet, original_volume
return
Assume we have a system with CPU which is fully compatible with Intel 8259 Programmable Interrupt Controller. So, this CPU use vectored interrupts, of course.
When one of eight interrupts occurs, PIC just asserts INTR wire that is connected to the CPU. Now PIC waits for CPU until INTA will be asserted. When so, PIC selects interrupt with the highest priority (depends on pin number), and then send its interrupt vector to data bus. I omitted some timing, but it doesn't matter for now, I think.
Here are questions:
How whole device, that causes interrupt, knows that his interrupt
request was accepted and it can pull off interrupt request? I read about 8259, but I didn't find it.
Is acknowledge device, whose interrupt was accepted, performed in ISR?
Sorry for my English.
The best reference is the original intel doc and is available here: https://pdos.csail.mit.edu/6.828/2012/readings/hardware/8259A.pdf It has full details of these modes, how the device operates, and how to program the device.
Caveat: I'm a bit rusty as I haven't programmed the 8259 in many years, but I'll take a shot at explaining things, per your request.
After an interrupting device, connected to an IRR ["interrupt request register"] pin, has asserted an interrupt request, the 8259 will convey this to the CPU by assserting INTR and then placing the vector on the bus during the three INTA cycles generated by the CPU.
After a given device has asserted IRR, the 8259's IS ["in-service"] register is or'ed with a mask of the IRR pin number. The IS is a priority select. While the IS bit is set, other interrupting devices of lower priority [or the original one] will not cause an INTR/INTA cycle to the CPU. The IS bit must be cleared first. These interrupts remain "pending".
The IS can be cleared by an EOI (end-of-interrupt) operation. There are multiple EOI modes that can be programmed. The EOI can be generated by the 8259 in AEOI mode. In other modes, the EOI is generated manually by the ISR by sending a command to the 8259.
The EOI action is all about allowing other devices to cause interrupts while the ISR is processing the current one. The EOI does not clear the interrupting device.
Clearing the interrupting device must be done by the ISR using whatever device specific register the device has for that purpose. Usually, this a "pending interrupt" register [can be 1 bit wide]. Most H/W uses two interrupt related registers and the other one is an "interrupt enable" register.
With level triggered interrupts, if the ISR does not clear the device, when the ISR does issue the EOI command to the 8259, the 8259 will [try to] reinterrupt the CPU using the vector for the same device for the same condition. The CPU will probably be reinterrupted as soon as it issues an sti or iret instruction. Thus, an ISR routine must take care to process things in proper sequence.
Consider an example. We have a video controller that has four sources for interrupts:
HSTART -- start of horizontal line
HEND -- end of horizontal line [start of horizontal blanking interval]
VSTART -- start of new video field/frame
VEND -- end of video field/frame [start of vertical blanking interval]
The controller presents these as a bit mask in its own special interrupt source register, which we'll call vidintr_pend. We'll call the interrupt enable register vidintr_enable.
The video controller will use only one 8259 IRR pin. It is the responsibility of the CPU's video ISR to interrogate the vidpend register and decide what to do.
The video controller will assert its IRR pin as long as vidpend is non-zero. Since we're level triggered, the CPU may be re-interrupted.
Here is a sample ISR routine to go with this:
// video_init -- initialize controller
void
video_init(void)
{
write_port(...);
write_port(...);
write_port(...);
...
// we only care about the vertical interrupts, not the horizontal ones
write_port(vidintr_enable,VSTART | VEND);
}
// video_stop -- stop controller
void
video_stop(void)
{
// stop all interrupt sources
write_port(vidintr_enable,0);
write_port(...);
write_port(...);
write_port(...);
...
}
// vidisr_process -- process video interrupts
void
vidisr_process(void)
{
u32 pendmsk;
// NOTE: we loop because controller may assert a new, different interrupt
// while we're processing a given one -- we don't want to exit if we _know_
// we'll be [almost] immediately re-entered
while (1) {
pendmsk = port_read(vidintr_pend);
if (pendmsk == 0)
break;
// the normal way to clear on most H/W is a writeback
// writing a 1 to a given bit clears the interrupt source
// writing a 0 does nothing
// NOTE: with this method, we can _never_ have a race condition where
// we lose an interrupt
port_write(vidintr_pend,pendmsk);
if (pendmsk & HSTART)
...
if (pendmsk & HEND)
...
if (pendmsk & VSTART)
...
if (pendmsk & VEND)
...
}
}
// vidisr_simple -- simple video ISR routine
void
vidisr_simple(void)
{
// NOTE: interrupt state has been pre-saved for us ...
// process our interrupt sources
vidisr_process();
// allow other devices to cause interrupts
port_write(8259,SEND_NON_SPECIFIC_EOI)
// return from interrupt by popping interrupt state
iret();
}
// vidisr_nested -- video ISR routine that allows nested interrupts
void
vidisr_nested(void)
{
// NOTE: interrupt state has been pre-saved for us ...
// allow other devices to cause interrupts
port_write(8259,SEND_NON_SPECIFIC_EOI)
// allow us to receive them
sti();
// process our interrupt sources
// this can be interrupted by another source or another device
vidisr_process();
// return from interrupt by popping interrupt state
iret();
}
UPDATE:
Your followup questions:
Why do you use interrupt disable on video controller register instead of mask 8259's interrupt enable bit?
When you execute vidisr_nested(void) function, it will enable nesting the same interrupt. Is it true? And is that what you want?
To answer (1), we should do both but not necessarily in the same place. They seem similar, but work in slightly different ways.
We change the video controller registers in the video controller driver [as it's the only place that "understands" the video controller's registers].
The video controller actually asserts the 8259's IRR pin from: IRR = ((vidintr_enable & vidintr_pend) != 0). If we never set vidintr_enable (i.e. it's all zeroes), then we can operate the device in a "polled" [non-interrupt] mode.
The 8259 interrupt enable register works similarly, but it masks against which IRRs [asserted or not] may interrupt the CPU. The device vidintr_enable controls whether it will assert IRR or not.
In the example video driver, the init routine enables the vertical interrupts, but not the horizontal. Only the vertical interrupts will generate a call to the ISR, but the ISR can/will also process the horizontal ones [as polled bits].
Changing the 8259 interrupt enable mask should be done in a place that understands the interrupt topology of the entire system. This is usually done by the containing OS. That's because the OS knows about the other devices and can make the best choice.
Herein, "containing OS" could be a full OS like Linux [of which I'm most familiar]. Or, it could just be an R/T executive [or boot rom--I've written a few] that has some common device handling framework with "helper" functions for the device drivers.
For example, although it's usual that all devices get their own IRR pin. But, it is possible, with level triggering, for two different devices to share an IRR. (e.g.) IRR[0] = devA_IRROUT | devB_IRROUT. Either through an OR gate [or wired OR(?)].
It's also possible that the device is attached to a "nested" or "cascaded" interrupt controller. IIRC [consult document], it is possible to have a "master" 8259 and [up to] 8 "slave" 8259s. Each slave 8259 connects to an IRR pin of the master. Then, connect devices to the slave IRR pins. For a fully loaded system, you can have 256 interrupting devices. And, the master can have slave 8259s on some IRR pins and real devices on others [a "hybrid" topology].
Usually, only the OS knows enough to deal with this. In a real system, a device driver probably wouldn't touch the 8259 at all. The non-specific EOI would probably have been sent to the 8259 before entering the device's ISR. And, the OS would handle the full "save state" and "restore state" and the driver just handles device specific actions.
Also, under an OS, the OS will call the "init" and "stop" routines. The general OS routines for this will handle the 8259 and call the device specific ones.
For example, under Linux [or almost any other OS or R/T executive], the interrupt sequence goes something like this:
- CPU hardware actions [atomic]:
- push %esp and flags register [has CPU interrupt enable flag] to stack
- clear CPU interrupt enable flag (e.g. implied cli)
- jump within interrupt vector table
- OS general ISR (preset within IVT):
- push all remaining registers to stack
- send non-specific EOI to 8259(s)
- call device-specific ISR (NOTE: CPU interrupt flag still clear)
- pop regs
- iret
To answer (2), yes, you are correct. It would probably interrupt immediately, and might nest (infinitely :-).
The simple ISR version is more efficient and preferable if the actions taken in the ISR are short, quick, and simple (e.g. just output to a few data ports).
If the required actions take a relatively long time (e.g. do intensive calculations, or write to a large number of ports or memory locations), the nested version is preferred to prevent other devices from having entry to their ISRs delayed excessively.
However, some time critical devices [like a video controller] need to use the simple model, preventing interruption by other devices, to guaranteed that they can complete in a finite, deterministic time.
For example, the video ISR handling of VEND might program the device for the next/upcoming field/frame and must complete this within the vertical blanking interval. They, have to do this, even if it means "excessive" delay of other ISRs.
Note that the ISR was "racing" to complete before the end of the blanking interval. Not the best design. I've had to program such a controller/device. For rev 2, we changed the design so the device registers were double-buffered.
That meant that we could set up the registers for frame 1 anytime during the [much longer] frame 0 display period. At VSTART for frame 1, the video hardware would instantly clock-in/save the double-buffered values, and the CPU could then setup for frame 2 anytime during the display of frame 1. And so on ...
With the modified design, the video driver removed the device setup from the ISR entirely. It was now handled from OS task level
In the driver example, I've adjusted the sequencing a bit to prevent infinite stacking, and added some additional information based upon my question (1) answer. That is, it shows [crudely] what to do with or without an OS.
// video controller driver
//
// for illustration purposes, STANDALONE means a very simple software system
//
// if it's _not_ defined, we assume the ISR is called from an OS general ISR
// that handles 8259 interactions
//
// if it's _defined_, we're showing [crudely] what needs to be done
//
// NOTE: although this is largely C code, it's also pseudo-code in places
// video_init -- initialize controller
void
video_init(void)
{
write_port(...);
write_port(...);
write_port(...);
...
#ifdef STANDALONE
write_port(8259_interrupt_enable |= VIDEO_IRR_PIN);
#endif
// we only care about the vertical interrupts, not the horizontal ones
write_port(vidintr_enable,VSTART | VEND);
}
// video_stop -- stop controller
void
video_stop(void)
{
// stop all interrupt sources
write_port(vidintr_enable,0);
#ifdef STANDALONE
write_port(8259_interrupt_enable &= ~VIDEO_IRR_PIN);
#endif
write_port(...);
write_port(...);
write_port(...);
...
}
// vidisr_pendmsk -- get video controller pending mask (and clear it)
u32
vidisr_pendmsk(void)
{
u32 pendmsk;
pendmsk = port_read(vidintr_pend);
// the normal way to clear on most H/W is a writeback
// writing a 1 to a given bit clears the interrupt source
// writing a 0 does nothing
// NOTE: with this method, we can _never_ have a race condition where
// we lose an interrupt
port_write(vidintr_pend,pendmsk);
return pendmsk;
}
// vidisr_process -- process video interrupts
void
vidisr_process(u32 pendmsk)
{
// NOTE: we loop because controller may assert a new, different interrupt
// while we're processing a given one -- we don't want to exit if we _know_
// we'll be [almost] immediately re-entered
while (1) {
if (pendmsk == 0)
break;
if (pendmsk & HSTART)
...
if (pendmsk & HEND)
...
if (pendmsk & VSTART)
...
if (pendmsk & VEND)
...
pendmsk = port_read(vidintr_pend);
}
}
// vidisr_simple -- simple video ISR routine
void
vidisr_simple(void)
{
u32 pendmsk;
// NOTE: interrupt state has been pre-saved for us ...
pendmsk = vidisr_pendmsk();
// process our interrupt sources
vidisr_process(pendmsk);
// allow other devices to cause interrupts
#ifdef STANDALONE
port_write(8259,SEND_NON_SPECIFIC_EOI)
#endif
// return from interrupt by popping interrupt state
#ifdef STANDALONE
pop_regs();
iret();
#endif
}
// vidisr_nested -- video ISR routine that allows nested interrupts
void
vidisr_nested(void)
{
u32 pendmsk;
// NOTE: interrupt state has been pre-saved for us ...
// get device pending mask -- do this _before_ [optional] EOI and the sti
// to prevent immediate stacked interrupts
pendmsk = vidisr_pendmsk();
// allow other devices to cause interrupts
#ifdef STANDALONE
port_write(8259,SEND_NON_SPECIFIC_EOI)
#endif
// allow us to receive them
// NOTE: with or without OS, we can't stack until _after_ this
sti();
// process our interrupt sources
// this can be interrupted by another source or another device
vidisr_process(pendmsk);
// return from interrupt by popping interrupt state
#ifdef STANDALONE
pop_regs();
iret();
#endif
}
BTW, I'm the author of the linux irqtune program
I wrote it back in the mid 90's. It's of lesser use now, and probably doesn't work on modern systems, but the FAQ I wrote has a great deal of information about interrupt device priorities. The program itself did a simple 8259 manipulation.
An online copy is available here: http://archive.debian.org/debian/dists/Debian-1.1/main/disks-i386/SpecialKernels/irqtune/README.html There's probably source code somewhere in this archive.
That's the version 0.2 doc. I haven't found an online copy of version 0.6 which has better explanation, so I've put up a text version here: http://pastebin.com/Ut6nCgL6
Side note: The "where to get" information in the FAQ [and email address] are no longer valid. And, I didn't understand the full impact of "spam" until I posted the FAQ and starting getting [tons of] it ;-)
And, irqtune even drew Linus' ire. Not because it didn't work but because it did: https://lkml.org/lkml/1996/8/23/19 IMO, if he had read the FAQ, he would have understood why [as what irqtune did is standard stuff to R/T guys].
UPDATE #2
Your new questions:
I think that you are missing a destination address in write_port(8259_interrupt_enable &= ~VIDEO_IRR_PIN). Isn't it so?
IRR register is read-only or r/w? If the second case, what is the purpose of writing into it?
Interrupt vectors are stored as logical addresses or physical address?
To answer question (3): No, not really [even if it seemed so]. The code snippet was "pseudo code" [not pure C code], as I mentioned in a code comment at the top, so technically speaking, I'm covered. However, to make it more clear, here is what the [closer to] real C code would look like:
// the system must know _which_ IRR H/W pin the video controller is connected to
// so we _hardwire_ it here
#define VIDEO_IRR_PIN_NUMBER 3 // just an example
#define VIDEO_IMR_MASK (1 << VIDEO_IRR_PIN_NUMBER)
// video_enable -- enable/disable video controller in 8259
void
video_enable(int enable)
{
u32 val;
// NOTE: we're reading/writing the _enable_ register, not the IRR [which
// software can _not_ modify or read]
val = read_port(8259_interrupt_enable);
if (enable)
val |= VIDEO_IMR_MASK;
else
val &= ~VIDEO_IMR_MASK;
write_port(8259_interrupt_enable,val);
}
Now, in video_init, replace the code inside STANDALONE with video_enable(1), and, in video_stop with video_enable(0)
As to question (4): We weren't really writing to the IRR, even though the symbol had _IRR_ in it. As mentioned in the code comments above, we were writing to the 8259 interrupt enable register which is really the "interrupt mask register" or IMR in the documentation. The IMR can be read from and written to by using OCW1 (see doc).
There is no way for software to access the IRR at all. (i.e.) There is no port in the 8259 to read or write the IRR value. The IRR is completely internal to the 8259.
There is a one-to-one correspondence between IRR pin numbers [0-7] and IMR bit numbers (e.g. to enable for IRR(0), set IMR bit 0), but the software has to know which bit to set.
Because the video controller is physically connected to a given IRR pin, it is always the same for a given PC board. The software [on older non-PnP systems] can't probe for this. Even on newer systems, the 8259 knows nothing of PnP, so it's still hardwired. The video controller driver programmer must just "know" what IRR pin is being used [by consulting the "spec sheet" or controller "architecture reference manual"].
To answer question (5): First consider what the 8259 does.
When the 8259 is intialized, the ICW2 ("initialization command word 2") gets set by the OS driver. This defines a portion of interrupt vector number the 8259 will present during the INTR/INTA cycle. In ICW2, the most significant 5 bits are marked T7-T3.
When an interrupt occurs, these bits are combined with the IRR pin number of the interrupting device [which is 3 bits wide] to form an 8 bit interrupt vector number: T7,T6,T5,T4,T3|I2,I1,I0
For example, if we put 0xD0 into ICW2, with our video controller using IRR pin 3, we'd have 1,1,0,1,0|0,1,1 or 0xD3 as the interrupt vector number that the 8259 will send to the CPU.
This is just a vector number [0x00-0xFF] as the 8259 knows nothing of memory addresses. It is the CPU that takes this vector number and, using the CPU's "interrupt vector table" [IVT], uses the vector number as an index into the IVT to properly vector the interrupt to an ISR routine.
On 80386 and later architectures, the IVT is actually called an IDT ("interrupt descriptor table"). For details, see the "System Programming Guide", chapter 6: http://download.intel.com/design/processor/manuals/253668.pdf
As, to whether the resulting ISR address from the IVT/IDT is physical or logical depends on the processor mode (e.g. real mode, protected mode, protected with virtual addressing enabled).
In a sense, all such addresses are always logical. And, all logical addresses undergo a translation to physical on each CPU instruction. Whether the translation is one-to-one [MMU not enabled or page tables have one-to-one mapping] is a question for "How has the OS set things up?"
Strictly speaking, there is no such thing
as "acknowledge an interrupt to device".
The thing that an ISR should do, is to handle
the interrupt condition. For example, if
the UART requested an interrupt because it
has an incoming data, then you should read
that incoming data. After that read operation,
UART no longer has the incoming data, so naturally
it stops asserting the IRQ line. Alternatively,
if your program no longer needs to read the
data and wants to stop the communication, it
would just mask the receiver interrupt via
the UART registers, and, once again, UART
will stop asserting the IRQ line. If the device
just wanted to signal you some state change,
then you should read the new state, and the
device will know that you have an up-to-date
state and will release an IRQ line.
So, in short: there is usually no any device-specific
acknowledge procedure. All you need to do is
to service an interrupt condition, after which,
that condition will disappear, voiding the
interrupt request.
Recently, I ran into a situation where I would like to use threaded IRQ's for a Keypad driver. For some background on threaded IRQ handlers:
http://lwn.net/Articles/302043/
From what I understand, every time an IRQ would occur the IRQ handler thread would be woken up. So, if i press KEY A, it wakes up the thread and it runs through to completion. Now, what would be the behavior should i press KEY B, when the handler thread is still running while servicing the IRQ from KEY A... Would the IRQ from KEY B be ignored ?
What would be the expected behavior ?
Ideally the system would always acknowledge the sequence of Key A->Key B.
However to acknowledge that a key was pressed, the system must do something at the point at which each key is pressed, I.e. when the keyboard interrupt occurs - at a minimum it must record the key presses, perhaps in a queue.
And from the perspective of a single processor, it can only do one thing at a time, so if it is in the middle of recording key press A, then it can't at the same time record key press B.
It would either have to abandon A and record B instead, or it would have to ignore B.
Thus the goal of interrupt handling is to minimise the amount of time the processor spends doing the minimum it needs to for acknowledging any given interrupt.
The goal of threaded interrupts is to push more of the work to separate threads, so that the minimum needed for acknowledging an interrupt is reduced, and therefore the time spent handling the interrupt (where it can't handle any other interrupts at the same time) is reduced.
Even then there is still no theoretical guarantee that the processor won't have to discard or ignore interrupts, but it does make it a lot less likely in practice.
For your specific example of key presses, if you were somehow able to be quick enough to press B before the processor had completed its minimum handling of A, then since both interrupts are from the same source, and therefore have the same priority, B would be ignored, and it would appear to you as if B was never pressed.
The way it works with interrupts is that processor will call an enabled interrupt over and over again until application clears the corresponding interrupt flag. So what you do is disable that particular interrupt in the hardware handler and wake up your thread. When hardware handler exits, interrupt flags will be set but the interrupt will not be called again. So you then in your thread checkeach flag and clear it as you go. When you detect that a flag for a keypress is set, you read out the key and then clear it. If a new key is pressed after you read data register and there is no fifo in hardware then that key press will be lost. You then clear the interrupt flag and enable the hardware interrupt again. The idea is that this process happens so fast that there is no way to lose a key because your thread will always run sooner than human can press another key.
In the situation such as usb (ie if you write a usb driver that communicates with pc) you have the option to tell usb peripheral when you are done reading data so it can tell the host it can accept more data. In that situation you can never lose data because you will read data out and clear the flag and only then tell the peripheral that you are ready. All the time until then the peripheral will tell the host that it is not ready so no data will be clocked in over the usb bus.
I need to swap Alt keys functionality in Windows 7. A big company needs that for old people that were writing on typewriters, which had diacritic characters key on the left side, but Win7 which they are working on now has right Alt for this purpose.
Two days of research brought me to a driver solution. I need source code for original Windows 7 drivers (two .sys files seem to be the keyboard drivers), and possibily to modify them in Windows DDK. Or I need to make an additional driver that would work with the default ones. As I can see, the solution would be in C or C++. But what way do I have to go to accomplish this? What steps should I take?
The limits are:
One system restart only for driver installation.
A simple way to swap Alt keys while working in Win7 (swap Alt keys by pressing them both).
No Win7 keyboard remapping which needs a restart.
Added later: I have everything I need, but not the code that will handle the swapping. For example, I've made a switch for right Shift and Enter, because there is only one scancode sent. But left Alt sends one and right Alt sends two scancodes:
VOID
KbFilter_ServiceCallback(
IN PDEVICE_OBJECT DeviceObject,
IN PKEYBOARD_INPUT_DATA InputDataStart,
IN PKEYBOARD_INPUT_DATA InputDataEnd,
IN OUT PULONG InputDataConsumed
)
/*++
Routine Description:
Called when there are keyboard packets to report to the Win32 subsystem.
You can do anything you like to the packets. For instance:
o Drop a packet altogether
o Mutate the contents of a packet
o Insert packets into the stream
Arguments:
DeviceObject - Context passed during the connect IOCTL
InputDataStart - First packet to be reported
InputDataEnd - One past the last packet to be reported. Total number of
packets is equal to InputDataEnd - InputDataStart
InputDataConsumed - Set to the total number of packets consumed by the RIT
(via the function pointer we replaced in the connect
IOCTL)
Return Value:
Status is returned.
--*/
{
PDEVICE_EXTENSION devExt;
WDFDEVICE hDevice;
hDevice = WdfWdmDeviceGetWdfDeviceHandle(DeviceObject);
devExt = FilterGetData(hDevice);
if (InputDataStart->MakeCode==0x1c)
InputDataStart->MakeCode=0x36;
else if (InputDataStart->MakeCode==0x36)
InputDataStart->MakeCode=0x1c;
else if (InputDataStart->MakeCode==0x9c)
InputDataStart->MakeCode=0xb6;
else if (InputDataStart->MakeCode==0xb6)
InputDataStart->MakeCode=0x9c;
(*(PSERVICE_CALLBACK_ROUTINE)(ULONG_PTR) devExt->UpperConnectData.ClassService)(
devExt->UpperConnectData.ClassDeviceObject,
InputDataStart,
InputDataEnd,
InputDataConsumed);
}
So I simply swap the scancodes of pressing and releasing both keys individually. Right Alt is sending two scancodes and I'm not sure if it does that by two calls of this function or makes two scancodes in the InputDataStart structure. I'll try to beep every Alt scancode but your help would be appreciated.
Solution:
if (InputDataStart->MakeCode==0x38 || InputDataStart->MakeCode==0xb8)
InputDataStart->Flags^=KEY_E0;
which swaps right-left Alt keys functionality.
Now I need to make the swapping configurable. For the best - by pressing both Alts.
I'm trying to implement a simple communication between two LPC1765 devices using RS-485. I'm using this example added to my menu system (it's a basic example for LPC17xx):
http://www.codeforge.com/read/155431/rs485.c__html
http://www.codeforge.com/read/155431/rs485.h__html
http://www.codeforge.com/read/155431/rs485test.c__html
So, both devices are properly initialized using RS485Init(). When I send data using RS485Send using a slave address as the first byte, the result is:
(1) if the devices are disconnected, transmitter receives its own communication (the contents of UARTBuffer are updated
(2) if the devices are connected, nothing happens -- transmitted buffer is lost somewhere (UARTBuffer doesn't change)
Now hardware should be properly connected so I'll just list things for reference. There is a U59 SN65HVD1781D driver on RS485_TXD/RXD, there are RS485_OF, RS485_MASTER_PWR and RS485_MASTER_MFAS and a voltage regulator. There is a RS485 slave detect circuit and UP/DOWN connections. Each device is connected with four contacts and they are (I think) RS485_UP, RS485_A+, RS485_B- and RS485_DOWN. There is a 4-pin connector both on top and on the bottom to connect devices in a sequence, where the topmost device would, if everything works, assume the status of a master over all bottom devices.
I got RS485 to work.
Using LPC17xx user manual at http://www.nxp.com/documents/user_manual/UM10360.pdf
In rs485.c in function RS485Init, direction control bits were wrong with PINSEL1 instead of PINSEL4; according to manual page 110, this should be correct (well, you can write 0x800 in many ways, but this is just a quick fix):
if (DIR_CTRL == 1){
LPC_PINCON->PINSEL4 |= 0x800;
LPC_UART1->RS485CTRL |= (RS485_DCTRL|RS485_SEL|RS485_OINV);
}else{
LPC_PINCON->PINSEL4 |= 0x8000;
LPC_UART1->RS485CTRL |= (RS485_DCTRL|RS485_SEL|RS485_OINV);
}
The second device has received my buffer.