Re: Graphics driver and CONFIG_ACPI
Hello again, I am having trouble getting information on how to have CONFIG_ACPI defined? I have been working on getting my radeon devices (Kaveri and OPAL XT) to work with NetBSD (9.2 - amd64). I have been successful in making the Kaveri device work on my system. I have found the bios in the ACPI tables. I also have revised the radeon_acpi_vfct_bios() function. But this function only works when CONFIG_ACPI is set/defined. So I have moved that function out of the CONFIG_ACPI condition. I am thinking that this might not be the correct way of doing this. I do not know where to define CONFIG_ACPI. It is not being defined (as it seems) for radeon, but for the i915 device it is being defined. I could do the same thing as it is done in the i915 driver code, but again, I am not sure about that either. Does anybody have an idea on where this definition (CONFIG_ACPI) should be defined, for radeon? Would appreciate any help you can provide. Thanks in advance. Regards, Riza On Sat, Nov 20, 2021 at 6:00 AM Riza Dindir wrote: > > Hello, > > I am trying to make the radeonr7 m265 display device to work on NetBSD > 9.2 (amd64). In the radeon_bios.c file there is a definition used, > named CONFIG_ACPI. Some functions are using this definition. I want to > enable this. Where can I do this? In the configuration file (GENERIC > for instance) or someplace else? > > Regards > Riza
re: kaveri_mec2.bin file missing
Riza Dindir writes: > Hello All, > > Finally... I was able to enable and use my Kaveri device > (0x1002/0x1309), at the end. It is using the external monitor and is > using the correct 1440x900 resolution. This is very nice. > > There is one thing that I would like to ask. > > There is a "CONFIG_ACPI" definition that is being used in the > radeon_bios file. I looked for this definition in the sources and > found that "sys/external/bsd/drm2/dist/drm/i915/i915_drv.h" has this > definition (that is the only place). > > I wanted to copy or do something similar in the radeon driver. But I > was not sure. Then I checked at runtime definitions CONFIG_ACPI and > NACPICA (as used in the i915 driver). The NACPICA has a value and is > > 0. And CONFIG_ACPI is not defined, as seen below. > > [10.911949] kern info: [drm] CONFIG_ACPI not set > [10.920577] kern info: [drm] NACPICA > 0 > > Do you have any ideas on why CONFIG_ACPI is not defined in radeon? > (Maybe this is not the correct place to ask this question). the ACPI code in the drm code base requires porting to netbsd, for both the radeon and the nouveau drivers. it's been a while since i was looking at it (i had nouveau compiling at some point). ie, it's not enabled because it doesn't compile there, it is only enabled on i915 because it does there. > If I were to submit patches, how can I submit these, where? sending patches to this list is good. (there's also tech-x11@ but this stuff is relevant for the console and other operations that don't need X, and is about the kernel side..) thanks. .mrg.
Re: wsvt25 backspace key should match terminfo definition
On Thu 25 Nov 2021 at 08:01:48 -0500, Mouse wrote: > One of my very-spare-time projects is to move input line editing out of > the kernel. Move it into a separate line-editor process and then you > can choose your input line editor just as you can, today, choose your > shell. I'm still mulling over the design issues involved, though, On the Amiga there was CONMAN: which could replace CON: as a console window, and it had nice extras like line editing. It also kept track of the user process' current directory so it could also do file name completion. On the V7 I used initially, a local patch had added more-like paging to the kernel's terminal driver. Quite useful on ADM-3a terminals without scrollback... I never got around to add this to NetBSD, unfortunately. But it's a lot less needed in an xterm. -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto signature.asc Description: PGP signature
Re: wsvt25 backspace key should match terminfo definition
>> Or, maybe have `erase=3D^?' and also a new `erase2=3D^H' [...] > That's an interesting idea... historically (and I mean decades) I > have setteled on choosing one (^H) and forcing all systems I used > over the years to use this one setting, but this might be more > convenient... One of my very-spare-time projects is to move input line editing out of the kernel. Move it into a separate line-editor process and then you can choose your input line editor just as you can, today, choose your shell. I'm still mulling over the design issues involved, though, since a lot of the line-editing programs want to do program-specific stuff like completion (of filenames, of command names, of internal keywords, whatever). Of course, there's xkcd-927 risk With a bit of care, it should even be possible to make it usable by programs that currently have to do their own input line editing (such as a curses IRC/ICB client); it's always bothered me that input line editing is sometimes done by the kernel and sometimes done by userland, and, except when the same person did both (and sometimes even then), they never seem to quite match up. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: wsvt25 backspace key should match terminfo definition
> key_backspacekbs kbsent by backspace key > key_dc kdch1 kDsent by delete-character > key Part of the confusion here is that this is not well-defined. Some keyboards have multiple keys which could reasonably be called a "delete-character key", and they often do not send the same thing. Similarly, is the BTW, since this is tech-kern, note that the wscons(4) manual page > tells a little white lie when it suggests that when in "vt100" mode > it "will work sufficiently as a VT220 emulator." It will, for most purposes. Most software does not use more than a few basic capabilities such as cursor positioning. Indeed, on most machines, wscons fails as a VT-100 - or VT-220 - emulator on one of the most basic counts: the size in lines, and not uncommonly columns, is wrong. Whether fortunately or unfortunately (I could argue either way), most software lets the tty size settings override the actual size of the terminal (supposedly) being emulated, even when that terminal was/is capable of only one size (or, as for the VT-100, a very few sizes). That's why mterm in "X3.64 + DEC extensions" mode sets $TERM to "decansi" rather than "vt100", even though in 80x24 size it's a better VT-100 emulator than many. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Emulating linux timer.. syscalls
Hello again, I wish if there something open i can help with. If it is. Could you recommend it. I have 7 months before my graduation, so given that i have other studies can you recommend something doable in 5 months and around 20 hour a week. Thanks Mohamed في الخميس، ٢٥ نوفمبر، ٢٠٢١ ١٠:٤٨ ص Stephen Borrill كتب: > On 24/11/2021 21:50, Mohamed Atef wrote: > > Hello there, > > I am a computer systems engineering student in my final year, i'd > > like to contribute to your community (Hint: I don't care about GSoC). > > I am interested in operating Systems, runtime systems, and compilers. > > I have strong C knowledge, C++, Data structures and algorithms, I am > > familiar with assembly (x86_x64, MIPs ). > > I am willing to start with easy projects and then develop myself to be > > able to bigger ones. > > I saw that one and it seems good to start with. > > I will install NetBsd on VMWare and try to get familiar with pkgsrc. > > Could you tell me please how to get the pre knowledge required for it? > > I wish to hear from you soon > > That sounds great, but I believe thorpej@ has already done most of the > work already to implement these natively: > > http://mail-index.netbsd.org/tech-kern/2021/08/05/msg027586.html > > This means the emulation part is (or will be) just a thin shin rather > than emulation. > > I'm not sure of its current state, but it wouldn't surprise me if Jason > would be happy for some help, especially with the ATF testing - perhaps > also with a view to how the Linux emulation may be tested. > > -- > Stephen >
Re: wsvt25 backspace key should match terminfo definition
At Tue, 23 Nov 2021 18:31:38 -0500, Greg Troxel wrote: Subject: Re: wsvt25 backspace key should match terminfo definition > > Johnny Billquist writes: > > >> For vt320 (where it *is* configurable) terminfo has > >> > >>$ infocmp -1 vt320 | grep kbs > >>kbs=^?, > > > > Which I think it should be. > > > But what does kbs mean? > > - the ASCII character sent by the computer to move the cursor left? > - the ASCII character sent by the BS key? > - the ASCII character sent by the DEL key that the uses uss to delete left? The answer to your question is actually clearly documented in the terminfo(5) manual page: key_backspacekbs kbsent by backspace key (note I fixed the typo (s/set/sent/) in my /usr/src/lib/libterminfo/term.h) I.e. if you have a terminal keyboard that has a key with the "Backspace" label, and another key with the "Delete" label, (or their "moral" equivalents, label-wise) then the terminfo entry's "kbs" value should give the character sequence sent when the user presses the "Backspace" key, and it should also have a value for "kdch1" giving the sequence sent when the user presses the "Delete" key: key_dc kdch1 kDsent by delete-character key For a configurable terminal (e.g. a real VT220 in vt100 mode) there should be a separate terminfo entry for the terminal in that different mode. In NetBSD's terminfo file this is currently "vt220d" (or "vt220-old", if that applies better to the actual terminal and/or keyboard in use). Note also, just to be more pedantic, the "k" prefix on terminfo(5) "Code" names (and the corresponding "key_" prefix on the "Long name" names) is the clue that the value for these codes is to represent the sequence sent by the terminal. This has been true since the 1980s when terminfo first came along. Also, BTW, the tradition for which key was the interrupt key (i.e. the one eventually modifiable using "stty intr") (and which key was "stty erase") changed depending on where/when you were. Some say it had an "East Coast / West Coast" division -- Bell Labs vs. UCB. I began in the early 1980s with the Bell Labs tradition (and terminals to match) that "stty intr" was set to ASCII DEL. Indeed that's all I could do since I started with Unix V7. As I understood it at the time this matched the Teletype "rubout" key that was used as the interrupt key (though I never used a real Teletype back then) [from tty(4) in the Unix 7th edition manual]: During input, erase and kill processing is normally done. By default, the character ‘#’ erases the last character typed [[ ]] DEL (Rubout) is not passed to a program but generates an interrupt signal which is sent to all processes with the associated control terminal. Normally each such process is forced to terminate, but arrangements may be made either to ignore the signal or to receive a trap to an agreed-upon location. See signal(2). Original V7 stty(1) didn't even let one change the "interrupt" key (though I believe V7's tty(4) TIOCSETP command would allow it to be changed). Of course back then the tty line discipline didn't do live erase or kill processing, and so the erase character was often left as "#" to avoid confusion (and "stty kill" was '@' -- modern email was a long way off!). The tradition of "stty intr" being ASCII DEL (by default) carried on into the AT releases as well, just as one would expect. However even right up to Unix System V Release 4.2 (about 1992) they hung on to '#' being the default erase character [this from SysVr4.2's termio(7)]: INTR (Rubout or ASCII DEL) generates a SIGINT signal. SIGINT is sent to all frequent processes associated with the control‐ ling terminal. Normally, each such process is forced to ter‐ minate, but arrangements may be made either to ignore the signal or to receive a trap to an agreed upon location. [See signal(5)]. ERASE (#) erases the preceding character. It does not erase beyond the start of a line, as delimited by a NL, EOF, EOL, or EOL2 character. Leaving "stty erase" as '#' changed quickly once one upgraded to a new enough system to have "ECHOE" (and "ECHOK") processing, including for BSD with the "new crt" line discipline, where live erase and kill processing could be enabled. Then one would set the erase character to what was most logical for the keyboard one was using. In Research Unix this all happened with the Unix 8th edition when the default for the tty line discipline's erase character was also changed to be the ASCII BS character, and the new "nttyld.c" implemented live erase and kill processing though none of this was properly documented. This is from
Re: wsvt25 backspace key should match terminfo definition
On Thu 25 Nov 2021 at 00:16:36 +, RVP wrote: > Or, maybe have `erase=^?' and also a new `erase2=^H' like FreeBSD does? It > seemed extravagant to have 2 erase chars. when I first encountered it, but, > now I'm beginning to see why... That's an interesting idea... historically (and I mean decades) I have setteled on choosing one (^H) and forcing all systems I used over the years to use this one setting, but this might be more convenient... (And I have been thinking of switching since ^? seems more prevalent on keyboards than ^H these days. But it would mean that I have to switch everything over more or less at once.) > -RVP -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto signature.asc Description: PGP signature
Re: Emulating linux timer.. syscalls
On 24/11/2021 21:50, Mohamed Atef wrote: Hello there, I am a computer systems engineering student in my final year, i'd like to contribute to your community (Hint: I don't care about GSoC). I am interested in operating Systems, runtime systems, and compilers. I have strong C knowledge, C++, Data structures and algorithms, I am familiar with assembly (x86_x64, MIPs ). I am willing to start with easy projects and then develop myself to be able to bigger ones. I saw that one and it seems good to start with. I will install NetBsd on VMWare and try to get familiar with pkgsrc. Could you tell me please how to get the pre knowledge required for it? I wish to hear from you soon That sounds great, but I believe thorpej@ has already done most of the work already to implement these natively: http://mail-index.netbsd.org/tech-kern/2021/08/05/msg027586.html This means the emulation part is (or will be) just a thin shin rather than emulation. I'm not sure of its current state, but it wouldn't surprise me if Jason would be happy for some help, especially with the ATF testing - perhaps also with a view to how the Linux emulation may be tested. -- Stephen
