tool_chain for 64 bit

[Christian Prochaska]

Hi Boris,

I'm trying to compile the new toolchain using tool/tool_chain x86.

does the attached patch help?

It might be necessary to delete the tool chain build directory before
running the tool_chain script again.

Christian

[Johannes Kliemann]

Hi,

we want to create a virtual keyboard for touch screen devices. This
shall be done by letting the keyboard provide an input service.
The problem here is that Nitpicker only provides input to the currently
active client. Since the keyboard needs to receive input events from the
touch screen, with this policy it would also receive its own sent keys.
We need a way to send these keys to another client while still receiving
further touch input.
How can this be done without compromising current security mechanism or
creating unnecessary large pieces of trusted code?

Regards
JK

[Norman Feske]

Hi Johannes,

Post by Johannes Kliemann
we want to create a virtual keyboard for touch screen devices. This
shall be done by letting the keyboard provide an input service.
The problem here is that Nitpicker only provides input to the currently
active client. Since the keyboard needs to receive input events from the
touch screen, with this policy it would also receive its own sent keys.
We need a way to send these keys to another client while still receiving
further touch input.
How can this be done without compromising current security mechanism or
creating unnecessary large pieces of trusted code?

that's an interesting problem. Thanks for bringing it up!

I guess that you are already using the input filter to feed the virtual
keyboard's events back to nitpicker?

Nitpicker's focus policy can be configured depending on the client's
label. Usually, the "click" policy is in effect, which means that a
click event implicitly changes the focus to the clicked-on client.
However, this policy is not always desired, like in your case or when
implementing a global menu. In the latter case, one wants to let the
menu handle a click yet retain the original focus. To accommodate such
scenarios, nitpicker supports the so-called "transient" focus policy
(documentation at [1]). If such a client is clicked-on, it receives the
press event and all subsequent events until all buttons/keys are released.

[1]
https://github.com/genodelabs/genode/blob/staging/repos/os/src/server/nitpicker/README#L105

I think that the transient focus policy is the right tool for your use
case if your virtual keyboards delivers its artificial events after the
release event (otherwise, nitpicker would send the artificial event to
the virtual keyboard which still has the transient focus).

For a practical example for configuring the transient focus feature,
please have a look at the gems/run/launcher.run script.

I'd be very interested in how this approach works for you. We previously
discussed on the list [2] that nitpicker's focus handling is still
somewhat limited. So your experience may give me valuable input for
possibly refining it.

[2]
https://sourceforge.net/p/genode/mailman/genode-main/thread/1a5cd577-1e4c-baea-8e83-8bb67e87bcb1%40nlcsl.com/#msg35798917

Cheers
Norman

[Johannes Kliemann]

Hi Norman,

thanks for your answer!

Post by Norman Feske
I guess that you are already using the input filter to feed the virtual
keyboard's events back to nitpicker?

We have not yet implemented the input service as we're yet thinking
about the overall architecture but that would have been our approach.

Post by Norman Feske
Nitpicker's focus policy can be configured depending on the client's
label. Usually, the "click" policy is in effect, which means that a
click event implicitly changes the focus to the clicked-on client.
However, this policy is not always desired, like in your case or when
implementing a global menu. In the latter case, one wants to let the
menu handle a click yet retain the original focus. To accommodate such
scenarios, nitpicker supports the so-called "transient" focus policy
(documentation at [1]). If such a client is clicked-on, it receives the
press event and all subsequent events until all buttons/keys are released.
[1]
https://github.com/genodelabs/genode/blob/staging/repos/os/src/server/nitpicker/README#L105
I think that the transient focus policy is the right tool for your use
case if your virtual keyboards delivers its artificial events after the
release event (otherwise, nitpicker would send the artificial event to
the virtual keyboard which still has the transient focus).
For a practical example for configuring the transient focus feature,
please have a look at the gems/run/launcher.run script.
I'd be very interested in how this approach works for you. We previously
discussed on the list [2] that nitpicker's focus handling is still
somewhat limited. So your experience may give me valuable input for
possibly refining it.
[2]
https://sourceforge.net/p/genode/mailman/genode-main/thread/1a5cd577-1e4c-baea-8e83-8bb67e87bcb1%40nlcsl.com/#msg35798917

Thanks for these sources. The transient policy sounds right for what we
want to do. Sending input events after release might be necessary
anyways if we want to handle longer presses.
I will give feedback when we are in progress with the implementation.

Regards,
JK