熟悉 notro/fbtft-spindle 的人，也許已經發現

sudo modprobe gpio_keys

# KEY_POWER 116 /* SC System Power Down */
sudo modprobe gpio_keys_device active_low keys=22:116

gpio_keys
gpio_keys_device active_low keys=22:116

pi@raspberrypi ~  ls
gpio_keys.ko
pi@raspberrypi /lib/modules/4.0.9-v7+/kernel/drivers/input/keyboard  

缺少了 gpio_keys_device ，將要如何定義顯示器上按鍵的呢？由於作者沒有玩過這個模組，所以不知道將來是否會再現？？就讓我們借此機會談談所謂的『事件驅動程式設計』。維基百科說︰

事件驅動程式設計（英語：Event-driven programming）是一種電腦程式設計模型。這種模型的程式執行流程是由使用者的動作（如滑鼠的按鍵，鍵盤的按鍵動作）或者是由其他程式的訊息來決定的 。相對於批次程式設計（batch programming）而言，程式執行的流程是由程式設計師來決定。批次的程式設計在初級程式設計教學課程上是一種方式。然而，事件驅動程式設計這種設計模型是在互動程式（Interactive program）的情況下孕育而生的。

，而且又講︰

Event-driven architecture (EDA) is a software architecture pattern promoting the production, detection, consumption of, and reaction to events.

An event can be defined as “a significant change in state“.^[1] For example, when a consumer purchases a car, the car’s state changes from “for sale” to “sold”. A car dealer’s system architecture may treat this state change as an event whose occurrence can be made known to other applications within the architecture. From a formal perspective, what is produced, published, propagated, detected or consumed is a (typically asynchronous) message called the event notification, and not the event itself, which is the state change that triggered the message emission. Events do not travel, they just occur. However, the term event is often used metonymically to denote the notification message itself, which may lead to some confusion.

This architectural pattern may be applied by the design and implementation of applications and systems which transmit events among loosely coupled software components and services. An event-driven system typically consists of event emitters (or agents), event consumers (or sinks), and event channels. Emitters have the responsibility to detect, gather, and transfer events. An Event Emitter does not know the consumers of the event, it does not even know if a consumer exists, and in case it exists, it does not know how the event is used or further processed. Sinks have the responsibility of applying a reaction as soon as an event is presented. The reaction might or might not be completely provided by the sink itself. For instance, the sink might just have the responsibility to filter, transform and forward the event to another component or it might provide a self-contained reaction to such event. Event channels are conduits in which events are transmitted from event emitters to event consumers. The knowledge of the correct distribution of events is exclusively present within the event channel. The physical implementation of event channels can be based on traditional components such as message-oriented middleware or point-to-point communication which might require a more appropriate transactional executive framework^[clarify].

Building applications and systems around an event-driven architecture allows these applications and systems to be constructed in a manner that facilitates more responsiveness, because event-driven systems are, by design, more normalized to unpredictable and asynchronous environments.^[2]

Event-driven architecture can complement service-oriented architecture (SOA) because services can be activated by triggers fired on incoming events.^[2][3] This paradigm is particularly useful whenever the sink does not provide any self-contained executive ^[clarify].

讀起來相當抽象，或許因為『事件』 ── 時空點上發生了一件事 ── 的『概念』本身就很抽象之故。假使我們再讀

Criticism_and_best_practice

Event-driven programming is widely used in graphical user interfaces, for instance the Android concurrency frameworks are designed using the Half-Sync/Half-Async pattern,^[1] where a combination of a single-threaded event loop processing (for the main UI thread) and synchronous threading (for background threads) is used. This is because the UI-widgets are not thread-safe, and while they are extensible, there is no way to guarantee that all the implementations are thread-safe, thus single-thread model alleviates this issue.

The design of those toolkits has been criticized, e.g., by Miro Samek, for promoting an over-simplified model of event-action, leading programmers to create error prone, difficult to extend and excessively complex application code. He writes,

Such an approach is fertile ground for bugs for at least three reasons:

1. It always leads to convoluted conditional logic.
2. Each branching point requires evaluation of a complex expression.
3. Switching between different modes requires modifying many variables, which all can easily lead to inconsistencies.

— Miro Samek, Who Moved My State?, C/C++ Users Journal, The Embedded Angle column (April 2003)

and advocates the use of state machines as a viable alternative.^{[2][clarification needed]}

能不對這個『範式』 Pattern 訝異嗎！那些常與『事件流』打交道的『程式師』，當真是武功高強的耶！？如果思索有一堆『獨立』運作的程式，分享某些共同『資料』與『設備』，各自以自己的『邏輯』解讀『事件流』，產生『事件流』，讀寫那些『資料』和『設備』，沒有良好的邏輯『規劃』，混亂的『狀態』祇靠想像可推知，程式『修補』以符合『目的』之術，能不應運而生的乎！！

如是當知『覺有情』之『觀世音』名號實難得難能也。

《佛說如幻三摩地無量印法門經》記載：

能仁作大師子吼，天人一切普得聞，我等今對世尊前，各發誠實最上願：我等乃至未來際，願我所行經多劫，隨入生死輪迴中，救度無數眾生類；我等今者以此緣，盡未來際悉思念，普為利樂諸眾生 ，於無邊劫行無懈；我等從今日已去，永滅貪瞋痴等垢，十方現在佛世尊，證我所說誠無妄；我等今發菩提心，不樂聲聞緣覺果，我等若有樂小心，決定當招妄語報；我所不樂二乘果，但以悲心為眾生，縱經俱胝多劫中，願我常行而不懈；如佛世尊所成就，如應佛剎廣莊嚴，願我當來得佛時，剎土倍多俱胝數；又願當來佛剎中，無有聲聞緣覺眾，純一菩薩所莊嚴，廣集無量諸智聚；願我得是莊嚴已，當令眾生得離垢，從諸佛法所出生，普使當持佛法藏；若我今時諸所說，真實無妄無別異，願此大海及山川，乃至大地皆震動 ；當發如是願言時，大地實時皆震動，不鼓音樂自然鳴，出微妙音遍十方；天雨眾華眾妙香，殊麗嚴好極可愛，俱胝百千妙天衣，周遍繽紛而散布。（這是觀自在菩薩、大勢至菩薩，在「師子遊戲金光王如來」處，一起首發菩提心的誓願。）