Re: ..Re AMDGPU Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?
> > Ignoring the parts of the shared > > drm/ttm code that would have to be updated the latest > > drivers/gpu/drm/amd in linux has over 1.5 million lines of code. Which > > is multiple times larger than the complete OpenBSD kernel source... > Despite everything you replied with, Jonathan's reply still accurately details the overriding concern. The code base is so huge, not only is porting a herculean task, but who wants this much code in their kernel to run the...video card? As a matter of fact, the existing AMD code can be extended to support the newer hardware without the huge import. Realistically, neither porting amdgpu nor extending the existing code are going to happen any time soon. There's no straightforward path to solve this problem.
Re: autri(4) disabled by default
On Tue, Jul 31, 2018 at 05:51:06PM +0100, Peter Kay wrote: > On 31 July 2018 at 14:22, Christian Weisgerber wrote: > > On 2018-07-31, Janne Johansson wrote: > > > >>> I see autri(4) is disabled by default in an amd64 kernel, probably > >>> others too, and has been for a very long time. > >> > >> Seems like it came over with the initial amd64 port from i386, and noone > >> tested it on amd64, so it never got enabled but remained commented out. > > > > It worked on sparc64, where it is enabled by default, back when I > > still had a Blade 100. > > I can confirm it does work fine! Checked some Chrome and mplayer, no > worries with audio. Not sure about MIDI, nothing comes out of the > sound card but not too fussed about that. > thanks for the confirmation. the midi(4) device is a simple serial port on the card used to connect midi gears (synthesizers, keyboards alike). So no sound is expected to come from the sound card when midi is used.
Re: autri(4) disabled by default
On 31 July 2018 at 14:22, Christian Weisgerber wrote: > On 2018-07-31, Janne Johansson wrote: > >>> I see autri(4) is disabled by default in an amd64 kernel, probably >>> others too, and has been for a very long time. >> >> Seems like it came over with the initial amd64 port from i386, and noone >> tested it on amd64, so it never got enabled but remained commented out. > > It worked on sparc64, where it is enabled by default, back when I > still had a Blade 100. I can confirm it does work fine! Checked some Chrome and mplayer, no worries with audio. Not sure about MIDI, nothing comes out of the sound card but not too fussed about that. autri0 at pci4 dev 0 function 0 "Trident 4DWAVE NX" rev 0x02: apic 5 int 16 audio0 at autri0 midi0 at autri0: <4DWAVE MIDI UART>
Re: autri(4) disabled by default
On 2018-07-31, Janne Johansson wrote: >> I see autri(4) is disabled by default in an amd64 kernel, probably >> others too, and has been for a very long time. > > Seems like it came over with the initial amd64 port from i386, and noone > tested it on amd64, so it never got enabled but remained commented out. It worked on sparc64, where it is enabled by default, back when I still had a Blade 100. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: autri(4) disabled by default
On Tue, Jul 31, 2018 at 11:43:37AM +0100, Peter Kay wrote: > I see autri(4) is disabled by default in an amd64 kernel, probably > others too, and has been for a very long time. > > I can't see any notice of why this is so, anyone know? > > My secondary system has a Trident 4DWave in it (yes, it's an old > soundcard. I grabbed it off ebay to work with Arca Noae, as it's not > so keen on a Soundblaster Live, and the motherboard is a server one > without any audio built in) > It could probably be enabled by default (like most of the pci audio interfaces). When you enable it, does it work?
Re: autri(4) disabled by default
Den tis 31 juli 2018 kl 12:47 skrev Peter Kay : > I see autri(4) is disabled by default in an amd64 kernel, probably > others too, and has been for a very long time. > > I can't see any notice of why this is so, anyone know? > > > Seems like it came over with the initial amd64 port from i386, and noone tested it on amd64, so it never got enabled but remained commented out. -- May the most significant bit of your life be positive.
Re: Keeping clear out of history
> Check out HISTCONTROL[1] and ignorespace in particular. Adding something > along the lines to your ~/.kshrc should do the trick: > > HISTCONTROL=ignorespace > bind -m '^L'='^U clear^J^Y' # note the intentional space before clear > > [1] https://man.openbsd.org/ksh#HISTCONTROL Actually this worked out to be the cleanest for my purposes. Again thank you. Ken
autri(4) disabled by default
I see autri(4) is disabled by default in an amd64 kernel, probably others too, and has been for a very long time. I can't see any notice of why this is so, anyone know? My secondary system has a Trident 4DWave in it (yes, it's an old soundcard. I grabbed it off ebay to work with Arca Noae, as it's not so keen on a Soundblaster Live, and the motherboard is a server one without any audio built in) PK
Re: Keeping clear out of history
Thanks all for not making me feel like I opened a flame war can of worms. I think the ignore dups solution is probably the most sensible for my purposes from what I have read from all the responses. Thank you. Ken
Re: Keeping clear out of history
On July 31, 2018 9:09:05 AM GMT+02:00, Solene Rapenne wrote: >Ken M wrote: >> OK, so confession 1, I am a long time bash user >> confession 2 all of my ksh experience is on solaris >> >> However in a when in Rome moment I am realizing how much I like ksh >in openbsd, >> but one minor thing. I don't like how much clear ends up in my >history file. So >> I am wondering what I can do to suppress a command going to history. >> >> >> Lets put my .profile here for reference >> >> # $OpenBSD: dot.profile,v 1.5 2018/02/02 02:29:54 yasuoka Exp $ >> # >> # sh/ksh initialization >> >> . /etc/ksh.kshrc >> >> >PATH=$HOME/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games:$HOME/.local/bin >> PS1="[\u@\h: \W]$ " >> HISTFILE=$HOME/.ksh_history >> HISTSIZE=1000 >> export PATH HOME TERM PS1 HISTFILE HISTSIZE >> >> # For now clearing out clear from history when starting >> sed -i '/^clear$/d' $HISTFILE >> >> bind -m '^L'=clear'^J' >> # I wish this worked >> # bind -m '^L'=clear'^J';sed -i '$d' $HISTFILE >> >> alias ll='ls -l' >> alias la='ls -la' >> alias watch='gnuwatch' >> >> >> As you can see I tried adding the ; sed after my bind, I also tried >it with && >> sed and that did not work. Both of course remove the sed from history >and not >> the clear. I guess I could remove the 2nd to last line. But before I >go that sed >> route is there a cleaner way to prevent a command from going to the >HISTFILE? >> >> Ken > >you can use HISTCONTROL=ignoredups so you would have only one entry for >"clear" >in your history That, or HISTCONTROL=ignorespace and prefix your clear with a space. Another obvious candidate is bind ^L=clear-screen which however I believe is still only available in -current. /Alexander
Re: Keeping clear out of history
Ken M wrote: ># I wish this worked ># bind -m '^L'=clear'^J';sed -i '$d' $HISTFILE You need to make sure that the sed command is inside the argument of bind. Something like this: bind -m '^L=^Uclear;sed -i \$d "$HISTFILE"^J^Y' The ^Y is just there to paste back the current line content when you press ^L in the middle of an existing line; the double quotes are there in case $HISTFILE contains a space. Note that, even if you change $HISTFILE, the clear command will still appear in ksh's history when you press the up arrow, so I'm not sure what you are trying to do is worth the trouble. Cheers, Philippe
Re: Keeping clear out of history
Ken M wrote: > OK, so confession 1, I am a long time bash user > confession 2 all of my ksh experience is on solaris > > However in a when in Rome moment I am realizing how much I like ksh in > openbsd, > but one minor thing. I don't like how much clear ends up in my history file. > So > I am wondering what I can do to suppress a command going to history. > > > Lets put my .profile here for reference > > # $OpenBSD: dot.profile,v 1.5 2018/02/02 02:29:54 yasuoka Exp $ > # > # sh/ksh initialization > > . /etc/ksh.kshrc > > PATH=$HOME/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games:$HOME/.local/bin > PS1="[\u@\h: \W]$ " > HISTFILE=$HOME/.ksh_history > HISTSIZE=1000 > export PATH HOME TERM PS1 HISTFILE HISTSIZE > > # For now clearing out clear from history when starting > sed -i '/^clear$/d' $HISTFILE > > bind -m '^L'=clear'^J' > # I wish this worked > # bind -m '^L'=clear'^J';sed -i '$d' $HISTFILE > > alias ll='ls -l' > alias la='ls -la' > alias watch='gnuwatch' > > > As you can see I tried adding the ; sed after my bind, I also tried it with && > sed and that did not work. Both of course remove the sed from history and not > the clear. I guess I could remove the 2nd to last line. But before I go that > sed > route is there a cleaner way to prevent a command from going to the HISTFILE? > > Ken you can use HISTCONTROL=ignoredups so you would have only one entry for "clear" in your history
Re: Keeping clear out of history
On Mon, Jul 30, 2018 at 08:11:44PM -0400, Ken M wrote: > OK, so confession 1, I am a long time bash user > confession 2 all of my ksh experience is on solaris > > However in a when in Rome moment I am realizing how much I like ksh in > openbsd, > but one minor thing. I don't like how much clear ends up in my history file. > So > I am wondering what I can do to suppress a command going to history. > > > Lets put my .profile here for reference > > # $OpenBSD: dot.profile,v 1.5 2018/02/02 02:29:54 yasuoka Exp $ > # > # sh/ksh initialization > > . /etc/ksh.kshrc > > PATH=$HOME/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games:$HOME/.local/bin > PS1="[\u@\h: \W]$ " > HISTFILE=$HOME/.ksh_history > HISTSIZE=1000 > export PATH HOME TERM PS1 HISTFILE HISTSIZE > > # For now clearing out clear from history when starting > sed -i '/^clear$/d' $HISTFILE > > bind -m '^L'=clear'^J' > # I wish this worked > # bind -m '^L'=clear'^J';sed -i '$d' $HISTFILE > > alias ll='ls -l' > alias la='ls -la' > alias watch='gnuwatch' > > > As you can see I tried adding the ; sed after my bind, I also tried it with && > sed and that did not work. Both of course remove the sed from history and not > the clear. I guess I could remove the 2nd to last line. But before I go that > sed > route is there a cleaner way to prevent a command from going to the HISTFILE? Check out HISTCONTROL[1] and ignorespace in particular. Adding something along the lines to your ~/.kshrc should do the trick: HISTCONTROL=ignorespace bind -m '^L'='^U clear^J^Y' # note the intentional space before clear [1] https://man.openbsd.org/ksh#HISTCONTROL
