Aros/開發者/GfxDriversDev
擴充套件AmigaGFX HIDD類，這樣我只需要新增尚不存在的螢幕模式。這帶來了一些問題：從現有的HIDD（已經是Graphics.hidd類的子類）繼承是否實用或可能？這可能，但可能不實用。沒有人嘗試過。AROS是一個研究作業系統，所以請隨意嘗試。:)
基於AmigaGFX驅動程式碼編寫新的驅動程式會更好還是更容易？最好是將新模式的支援新增到現有的Amiga驅動程式中。我認為NatAMI晶片組是AGA的超集。多個HIDD會同時載入並共享資源嗎？這是真的嗎？載入 - 是的。共享資源 - 如果它們被設計為這樣做，那麼是。但是它可能會有問題。我想繼承AmigaGFX驅動程式的原因是為了避免問題並使驅動程式更易於維護。如果擴充套件一個驅動程式以實現另一個驅動程式是有問題的，我將不得不修改AmigaGFX HIDD。點陣圖HIDD的子類化在某些情況下已經完成。VESA點陣圖是通用塊狀點陣圖的子類，據我所知，AmigaGFX點陣圖是平面點陣圖類的子類。
isCyberModeID() 在尋找什麼？它標記的是缺少Copper還是存在塊狀畫素？塊狀畫素格式。它如何使用？AROS本身不使用它。
當我考慮這一點時，在Indivision ECS或GraffitiGraphics/Indivision AGA 2.0支援中新增塊狀支援將需要類似的方法，並且還需要這些問題的答案。我已經瀏覽了WikiBooks上的文件，看起來這可能，但我仍然不確定。
NatAmi中沒有小端模式，所以我知道我可以放棄這些模式。R8G8B8模式儲存為3個位元組平面，而不是純塊狀3位元組畫素寬度，所以我不知道該怎麼辦，除了在modes列舉中新增混合模式。最重要的是，我需要知道如何告訴AROS硬體支援哪些模式。（我在natamirtg.h中看到一個SUPPORTMASK值，但不知道它是否只是與HIDD的其餘部分進行通訊，或者是否用於更全域性地與CGFX.library進行通訊。
我想我的主要問題是這兩個：是否有更好的模板可以讓我遵循？UAEGFX可能不是最佳選擇，因為它有醜陋的模式ID重新對映，模式列表來自UAE，所有模式設定和blit函式都呼叫UAE本機程式碼。可能更容易先檢查像vga或vesa這樣的簡單驅動程式，它們具有“正常”模式生成程式碼，並且沒有任何“隱藏”程式碼。
如果您需要與原始AOS程式相容的AOS式模式ID範圍，可以隨時新增模式ID重新對映。
最重要的是，我需要知道如何告訴AROS硬體支援哪些模式。
在gfx類的New方法中，您需要構建一個“畫素格式”和“同步”的標記列表，然後將其傳遞給父類。請參見AROS/workbench/hidds/hidd.nouveau/nouveauclass.c，第355行
struct TagItem modetags[] = {
{ aHidd_Gfx_PixFmtTags, (IPTR)pftags_24bpp },
{ aHidd_Gfx_PixFmtTags, (IPTR)pftags_16bpp },
{ TAG_MORE, (IPTR)syncs }, /* FIXME: sync tags will leak */
{ TAG_DONE, 0UL }
};
struct TagItem mytags[] = {
{ aHidd_Gfx_ModeTags, (IPTR)modetags },
{ TAG_MORE, (IPTR)msg->attrList }
};
struct pRoot_New mymsg;
mymsg.mID = msg->mID;
mymsg.attrList = mytags;
msg = &mymsg;
o = (OOP_Object *)OOP_DoSuperMethod(cl, o, (OOP_Msg)msg);
在workbench/hidds/hidd.name中
manu_init.c manu_lowlevel.c manu_i2c.c manu_bitmap.c name_class.c name_memory.c name_bios.c name_driver.c name_accel.c planarbm.c bitmap.c compositing_class.c
manu_bitmap.c - VOID 方法
Dispose Get Clear FillRect DrawLine DrawRect DrawPolygon PutPixel DrawPixel DrawEllipse ReleaseDirectAccess PutImageLUT PutAlphaImage PutImage GetImage PutTemplate PutPattern
name_class.c - OOP_Object 和 VOID
Show NewBitMap New CopyBox SetCursorShape SetCursorVisible SetCursorPos Get Set
aHidd_BitMap_Width aHidd_BitMap_Height aHidd_BitMap_PixFmt aHidd_PixFmt_Depth aHidd_BitMap_FrameBuffer aHidd_Sync_PixelClock aHidd_Sync_HDisp aHidd_Sync_VDisp aHidd_Sync_HSyncStart aHidd_Sync_VSyncStart aHidd_Sync_HSyncEnd aHidd_Sync_VSyncEnd aHidd_Sync_HTotal aHidd_Sync_VTotal
一個位圖是記憶體點陣圖，另一個是顯示驅動程式的點陣圖。
目前，驅動程式在這種情況下呼叫DoSuperMethod。我可以想象它可以被最佳化得更多（類似於ATI驅動程式中的PutImage方法），如果目標點陣圖由驅動程式維護，則可以使用DMA引擎。
僅供參考：在這種情況下，記憶體點陣圖在其佈局上可能有一些限制（例如對齊要求）。例如，在我的Windows GDI驅動程式中，BlitColorExpansion() 與planarbm類的真實平面點陣圖完美配合，但是在這種情況下，此點陣圖必須使用顯示HIDD的NewBitMap() 方法建立。這意味著它實際上必須是顯示點陣圖的朋友（或顯示點陣圖朋友的朋友...）。
這使我們重新審視點陣圖友誼的含義。目前，點陣圖繼承了其朋友點陣圖的所有特性（內部佈局、畫素格式和類）。如果它獲得了另一個類（因為畫素格式是顯式指定的），那麼友誼實際上就破裂了。在新情況下，這並不意味著友誼完全破裂，因為NewBitMap() 仍然可以對點陣圖進行一些調整。它們只是一些更遙遠的朋友......
但是，如果點陣圖是在沒有朋友規範的情況下建立的，並且是在沒有顯式顯示模式規範的情況下建立的，那麼它將是一個純基於RAM的點陣圖。圖形驅動程式不太可能以加速方式處理它（因為對齊方式不正確）。所以問題是 - 實施這種機制有多安全？我們是否會最終得到速度緩慢的圖形，因為設計上無法加速，因為一半的點陣圖將在沒有任何朋友規範的情況下建立。
圖形驅動程式能夠以加速方式處理來自任意格式點陣圖（沒有任何強制對齊等）的blit的可能性有多大？
在這種情況下，DoSuperMethod 呼叫很慢，但很安全，因為它將使用兩個驅動程式的GetPixel/PutPixel 方法以安全的方式傳輸點陣圖。當然，這種情況也可以進一步最佳化。
所以，卡實際上可以透過DMA相互傳輸資料？
fakegfxhidd（軟體滑鼠游標）可以支援ShowViewPorts() 嗎？不需要合成/多個視窗，只需要獲取視窗資訊。
檢查PrepareViewPorts。它始終被呼叫。順便說一下，它直接獲取 struct View*。您可以在視窗鏈中的第一個點陣圖中記住您收集的資訊。這將被傳遞給Show。在fakegfx中實現ShowViewPorts 似乎是有問題的，因為它與幀緩衝區無法很好地共存。順便說一下，您也可以實現 ShowViewPorts，它執行一些準備工作並返回 FALSE。
幀緩衝區驅動程式和映象驅動程式有什麼區別？在幀緩衝區驅動程式中，實際上只有一個螢幕上的點陣圖，該點陣圖會不斷顯示，而Show 實際上是透過複製內容和替換點陣圖物件來模擬的。映象實際上是避免緩慢的VRAM讀取。映象驅動程式不使用VRAM來儲存點陣圖物件，而是使用映象緩衝區，並在需要時更新VRAM。由於映象驅動程式具有顯示點陣圖的完整副本，因此不需要模擬Show。相反，它只是將不同的映象附加到VRAM。因此，VESA 和 VGA 驅動程式不需要標記為幀緩衝區驅動程式，因為它們使用映象？是的，它們不需要。映象驅動程式自己處理VRAM，它們不需要Show 模擬。開啟幀緩衝區對它們來說只是浪費記憶體。順便說一下，我的驅動程式在這樣做時返回 NULL。這些驅動程式透過將 aHidd_Gfx_NoFrameBuffer 屬性的值返回為 TRUE 來表明這一點。
嘗試使合成類對驅動程式也變得可共享。這種方法有一個優點。對於映象驅動程式來說它更快，因為您可以直接將點陣圖合成到VRAM中。所以，從長遠來看，我們可能會最終使用一個基礎合成類和一系列子類來滿足不同的驅動程式型別。順便說一下，也許軟體精靈模擬也可以這樣做。將它的影像直接放入VRAM 中比由 fakegfx 支援的複製更快，並且閃爍更少。VESA 驅動程式現在將在一個游標大小的臨時點陣圖上疊加游標，並在之前將正確的背景部分複製到其中。我嘗試過將游標直接透過 alpha blit 方式寫入VRAM，但這太麻煩了，因為無法在VRAM 上使用 PutAlphaImage 來支援所有顏色深度。
此外，正如 GMA 所做的那樣，驅動程式可以在 ShowViewPorts 中檢測到是否只有最頂層的螢幕可見，並停用映象，這樣每個 blit 不會被重複。不幸的是，不會。映象不僅僅是一種進行合成的方式。它的主要目的是避免緩慢的VRAM讀取。如果您繞過了它，並且只是將點陣圖放在VRAM 中（幀緩衝區方法），它會非常慢。這就是為什麼在 VGA 和 VESA 中進行映象的原因。
CreateVLayerHandleTagList() 和 DeleteVLayerHandle() 是新增到圖形驅動程式類中的兩個方法，以及為疊加層類開發的一些屬性。目前沒有疊加層基類，因為我認為在那裡放什麼。
Intuitions 真的需要了解物理顯示器嗎？將來，當我實現整個類時，它將能夠維護有關它們在物理空間中的相對位置的資訊。這對於正確處理多顯示器輸入是必要的。
其餘部分是對MorphOS API的重新實現。我決定不再重新發明輪子，而是使用現有的API。我希望保持擴充套件之間的相容性。
到目前為止，我們擁有乾淨的層：Intuition 位於 Graphics 之上，Graphics 位於 Graphics HIDD 之上。現在，我們引入了 Intuition 和 Graphics HIDD 之間的連線，以便 Monitor 類可以讀取 HIDD 資訊。Intuition 已經使用直接 HIDD 訪問 - 在 pointerclass 中，它將調色盤附加到精靈點陣圖。是的，它有什麼不好？即使是一個普通的應用程式也可能會查詢 HIDD 資訊，如果它想要的話。
Monitorclass 是 BOOPSI 的一部分，而 BOOPSI 又是 Intuition 的一部分。程式碼本身可以移到 graphics.library，但仍然需要 Intuition 才能呼叫 MakeClass()。
這裡有些人反對新增越來越多的私有函式。我們的 graphics.library 已經為 CGX 操作提供了 7 個私有函式，還有一個 AROS 特定的 AddDisplayDriverA()。我認為這已經足夠了。事實上，我做了完全按照建議做的事情——將 AROS 特定的功能移到一個新的 AROS 特定的模組。在這種情況下，這個模組已經存在——它是 graphics.hidd。在其之上執行的元件可以在需要時直接與它通訊。
說實話，我只不喜歡一件事——我將 AddDisplayDriverA() 宣告為公共函式。我應該從一開始就實現 monitorclass，Intuition 會在建立 monitorclass 物件時呼叫私有的 AddDisplayDriverA()。好吧，已經做完了。我不會重寫整個東西。現在，AddDisplayDriverA() 會在驅動程式安裝成功後建立 monitorclass 物件。但是，AddDisplayDriverA 不是 graphics.library 的函式嗎？這意味著提供功能的模組（graphics.library）現在將依賴於使用功能的模組（intuition.library）。這就像瀏覽器依賴於網路堆疊，同時網路堆疊又依賴於瀏覽器一樣。在這個更改之後，即使沒有 intuition，graphics.library 還能執行嗎？我認為，這也是將 monitor class 分離到另一個模組的理由。MorphOS 可能把它放在了 Intuition 中，但我們不必這樣做——我們可以保留介面，但以更合適的形式實現它。
是的，在一方面。但是我不會稱之為嚴格的依賴關係。AddDisplayDriverA() 在其末尾可能會做以下事情
if (!IntuitionBase)
IntuitionBase = OpenLibrary("intuition.library", 50);
if (!IntuitionBase)
return ret;
mon = NewObjectA(NULL, "monitorclass", tags);
這樣，graphics.library 就不再使用 intuition.library 的任何功能。它只是為 intuition.library 提供一些資訊（告訴它新的顯示器）。
類似的程式碼已經存在於 graphics.hidd 的 sync 類中，它手動開啟 graphics.library，建立 MonitorSpec 結構並將它新增到 MonitorList 中。
graphics.hidd 沒有 RastPort 結構，這意味著它不與 Layers 一起工作。這意味著——沒有視窗和螢幕。理論上，可以在某種簡單的嵌入式系統上使用 HIDDs 進行繪圖，該系統不執行多個應用程式也不需要視窗。它類似於在 AmigaOS 上手動構建 ViewPort 和 View（這也適用於 AROS）。
Linux 驅動程式堆疊。
有關編寫驅動程式的資訊，請參閱 Unix X 伺服器圖形驅動程式 並學習 原始碼
參見 此處
完成 狀態
HIDDM_Graphics_Cmd HIDDM_Graphics_MCmd HIDDM_Graphics_MQCmd HIDDM_Graphics_QCmd HIDDV_Graphics_Cmd_CheckTOF HIDDV_Graphics_Cmd_Clear HIDDV_Graphics_Cmd_CopyArea HIDDV_Graphics_Cmd_CreateBitMap HIDDV_Graphics_Cmd_CreateGC HIDDV_Graphics_Cmd_DeleteBitMap HIDDV_Graphics_Cmd_DeleteGC HIDDV_Graphics_Cmd_DepthArrangeBitMap HIDDV_Graphics_Cmd_DrawEllipse HIDDV_Graphics_Cmd_DrawLine HIDDV_Graphics_Cmd_DrawPolygon HIDDV_Graphics_Cmd_DrawRect HIDDV_Graphics_Cmd_DrawText HIDDV_Graphics_Cmd_FillEllipse HIDDV_Graphics_Cmd_FillPolygon HIDDV_Graphics_Cmd_FillRect HIDDV_Graphics_Cmd_FillSpan HIDDV_Graphics_Cmd_FillText HIDDV_Graphics_Cmd_GetPixel HIDDV_Graphics_Cmd_MoveBitMap HIDDV_Graphics_Cmd_SetPixel HIDDV_Graphics_Cmd_ShowBitMap HIDDV_Graphics_Cmd_Special HIDDV_Graphics_Cmd_WaitTOF