OSDev.org

Posted: **Sat Jan 14, 2017 10:58 am**

I'm trying to get my keyboard handler to be able to work properly.

However, I can't seem to get a grip on this.

My tries:

Polling:

Polling is the only one that I can get working and actually go to the next character. However, this puts way too many characters when I hold this for less than a second. This can display upwards of 4 characters when I hold the key for 0.75 seconds, instead of the normal 1 character. This also displayed unwanted spaces/nulls.

Using interrupts:

Using the (proper) normal way that uses Interrupts doesn't help, too. This displays absolutely nothing. Nothing. Nothing happens. It's like it's frozen.

Nothing displays on the screen.

Posted: **Sat Jan 14, 2017 11:00 am**

By looking at your GitHub repo, you don't know how to properly handle interrupts.
Seriously, why not try to do it yourself once?

Posted: **Sat Jan 14, 2017 11:05 am**

omarrx024 wrote:By looking at your GitHub repo, you don't know how to properly handle interrupts.
Seriously, why not try to do it yourself once?

What? I did write most of the code myself.

Posted: **Sat Jan 14, 2017 11:06 am**

DixiumOS wrote:What? I did write most of the code myself.

Why don't you read the wiki and then try to write code yourself?

Posted: **Sat Jan 14, 2017 11:18 am**

omarrx024 wrote:
DixiumOS wrote:What? I did write most of the code myself.
Why don't you read the wiki and then try to write code yourself?

I do.
And seriously, if you want to help someone, don't bring up a completely different topic with no relation to this and then say bad things. Please, don't.

If you don't feel like helping, then don't. Just don't bring up a discussion that never solved anything.

Posted: **Sat Jan 14, 2017 11:40 am**

DixiumOS wrote:
omarrx024 wrote:
DixiumOS wrote:What? I did write most of the code myself.
Why don't you read the wiki and then try to write code yourself?
I do.
And seriously, if you want to help someone, don't bring up a completely different topic with no relation to this and then say bad things. Please, don't.

If you don't feel like helping, then don't. Just don't bring up a discussion that never solved anything.

Do you not understand why people are getting frustrated though? You don't really seem to read what people say and make thousands of threads on the same topic.

Posted: **Sat Jan 14, 2017 11:44 am**

zenzizenzicube wrote:snip

Do I? Oh, sorry.

Anyway, can we return 0; to our question?

Posted: **Sat Jan 14, 2017 11:58 am**

Have you tried putting:

Code: Select all

terminal_writechar("A", ...);

right at the start of your keyboard handler, or even inside the IRQ handler, just to make sure it actually gets called?
Are you sure the compiler doesn't do anything unexpected/undesired in your ISRs, such as changing the stack pointers (esp/ebp)?

I think the article about ISRs might be of help.

Posted: **Sat Jan 14, 2017 1:24 pm**

sleephacker wrote:Have you tried putting:
Code: Select all
terminal_writechar("A", ...);
right at the start of your keyboard handler, or even inside the IRQ handler, just to make sure it actually gets called?
Are you sure the compiler doesn't do anything unexpected/undesired in your ISRs, such as changing the stack pointers (esp/ebp)?

I think the article about ISRs might be of help.

Doesn't work...

Ugh, looks like I'll need to fix my IDT code.

EDIT: Nope. The keyboard just went on vacation and forgot to fire IRQ1.

Posted: **Sat Jan 14, 2017 1:54 pm**

DixiumOS wrote:
sleephacker wrote:Have you tried putting:
Code: Select all
terminal_writechar("A", ...);
right at the start of your keyboard handler, or even inside the IRQ handler, just to make sure it actually gets called?
Are you sure the compiler doesn't do anything unexpected/undesired in your ISRs, such as changing the stack pointers (esp/ebp)?

I think the article about ISRs might be of help.
Doesn't work...

Ugh, looks like I'll need to fix my IDT code.

If I could offer two pieces of advice: first, if you are using GCC for your compiler, and want to use a C function for an interrupt handler, use the __attribute__ ((interrupt)) function attribute, rather than emitting an IRET manually. It does require a certain amount of GCC-specific and non-portable code, but since this is an interrupt handler that's hardly a concern. Take note that you will need a data structure for representing the interrupt frame, as explained in the GCC documents and the Intel manuals.

Second, you should be redirect all of the interrupt vectors to a single IDT entry rather than having several dozen which are repeating the same code. Indeed, I would recommend initializing the entire IDT in this manner (with a default handler that issues a system initialization error message), and then adding the actual entries you need, just as a backstop in case of a programming error.

Code: Select all

void addisrfunctions(void) {
    for (int i = 0; i < 256; i++) {
        idt_set_gate(i, (unsigned)isr_default, 0x08, 0x8E);
    }

    // now that you have everything initialized, add the 
    // actual interrupt handlers to the vectors you want 

}

Code: Select all

__attribute__ ((interrupt)) void isr_default(struct interrupt_frame *frame) {
    // for now, just put this as a stub that will panic
    // the kernel, you can write a more elegant
    // default handler later
    
    terminal_clrscr();
    terminal_writestring("Fatal error - unsupported interrupt", BLACK, WHITE, 0, 0);
    panic();    // you will need to write this function, I guess
}

This is just off the top of my head; you'll need to work the details out as you you can.

Posted: **Sat Jan 14, 2017 2:03 pm**

Hi,

Another problem is that he doesn't send an EOI in interrupt handlers.

Regards,
glauxosdever

Posted: **Sat Jan 14, 2017 2:42 pm**

Optimized my IDT code to work and now it's randomly issuing interrupts before triple faulting (literally 7600 lines of logs from QEMU before it triple faulted). It isn't at executing interrupts, but rather loading the IDT.

The last few lines tell that it's crashing at pop %ds in isr8 and pop %ds in isr13.

EDIT: I also realized as this is getting to the last line, esp decreases.

EDIT: Now it works. And IRQ1 never fires. Dammit.

Posted: **Sat Jan 14, 2017 3:43 pm**

Just to say: the IDT is fine as IRQ0 gets fired constantly by the PIT. It is seen in the QEMU logs.
The IRQ1 is correctly loaded and is the proper example of a keyboard handler.

Resuming to the question:

My IRQ1 handler never gets called by my keyboard. IRQ0, however, gets constantly called, and the QEMU logs report it.

How do i fix this?
seesignatureforcode

Posted: **Sat Jan 14, 2017 3:52 pm**

Did you unmask IRQ1 when setting up the PIC?
Did you configure the keyboard to send interrupts during initialisation?

Posted: **Sat Jan 14, 2017 4:00 pm**

sleephacker wrote:Did you unmask IRQ1 when setting up the PIC?
Did you configure the keyboard to send interrupts during initialisation?

Nope about unmasking.
Now it works except i only get one IRQ, and i do send an EOI.

OSDev.org

How do i get my keyboard handler to work?

How do i get my keyboard handler to work?

Re: How do i get my keyboard handler to work?

Re: How do i get my keyboard handler to work?

Re: How do i get my keyboard handler to work?

Re: How do i get my keyboard handler to work?

Re: How do i get my keyboard handler to work?

Re: How do i get my keyboard handler to work?

Re: How do i get my keyboard handler to work?

Re: How do i get my keyboard handler to work?

Re: How do i get my keyboard handler to work?

Re: How do i get my keyboard handler to work?

Re: How do i get my keyboard handler to work?

IRQ1 never gets fired

Re: IRQ1 never gets fired

Re: IRQ1 never gets fired