From nobody Tue Jan 4 17:23:26 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 66AB7193796F for ; Tue, 4 Jan 2022 17:23:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSzwp27rJz4jxl for ; Tue, 4 Jan 2022 17:23:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa36.google.com with SMTP id 78so2301644vkz.7 for ; Tue, 04 Jan 2022 09:23:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OAq/yllwcxK+EqpAmGhPVJvb4ATaQfNjn9RGR6MadXg=; b=UYA1AwHXxSzJAcV+ZnPh+anfFgZaEgdvy25OT5BDd0fTCPa9wPU8SZOfun+Ro6udgU VAvc3NMgdG33WAuVipTgU+3oHKY7mP3ck/J4pdKjV+G9E2sIwEWAMkZPHQ8Ue+tHx1X+ 2YFYRWahHV7KYBrGeL8w1unysO+BA9JKaVhHve+v/FfTOnNvtUv18rQdu5yixZiuIpY+ g/7vfi2xZXo+GyA8etAT7c5bhkr68lOy5X90VRBBBx99ox6a6aePzSAjTlV4Lpf5Q5wl JQ0Q+ItEOUkU8fCh2v5cmx/esS0MVyIzozF8hgLMaur9h9YBkMFc8dkEI8EPCShWcaby r/uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OAq/yllwcxK+EqpAmGhPVJvb4ATaQfNjn9RGR6MadXg=; b=GjpPghBLbcTPEgLCRxXw4lkDJ8MfoxrSevVUjpITocnFtngRAqg7Tr/1K7HukODXDs 8gQppNeN00q5D2pdPAmRKUqU9jzNkepGTmuiaq6W45JBvHWH0otue/+xZFHYNQ+HQOvD MYCFGJixicvfi5pMX9WQh6j0J+waHPh0cGeBV7k8DctxMadyatd7xKGHxB3aUTvhA5UH 8pq0aaBHZHPKYIy1z0kmsj5hswSBnzFMXqyORKadR9tt8aTXd6MIKfcrC6G6efWeZbBq dHqi+Y3Q0uTjjszfKv6RcVGDAyH+XJ99NiFN0yFIZMmFTkMSjaerynC5JzPX/T78Aent Zlfg== X-Gm-Message-State: AOAM531C29XYpsSWG6A+KD7bX/5Db4S5AiBGHM1z8gJdCzOI4pq/88m0 97DA4OecL4tn+RL3x+1wSjOErdCXEP4kM3lituAhwQ== X-Google-Smtp-Source: ABdhPJy286+1mjCWYIQG/rGtvnSHz7or6rlvAQeU52W+nR9upAxVZkqFCSHIcnIp5iozVvcyzia1SunkgRE751HeA18= X-Received: by 2002:a05:6122:e12:: with SMTP id bk18mr18047033vkb.40.1641317017691; Tue, 04 Jan 2022 09:23:37 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> <864k6qj6x6.fsf@phe.ftfl.ca> <86zgoihs64.fsf@phe.ftfl.ca> In-Reply-To: From: Warner Losh Date: Tue, 4 Jan 2022 10:23:26 -0700 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Stefan Blachmann Cc: Joseph Mingrone , =?UTF-8?B?w5Z6a2FuIEtJUklL?= , Michael Schuster , Kyle Evans , Karel Gardas , FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000cdb91c05d4c4e5c2" X-Rspamd-Queue-Id: 4JSzwp27rJz4jxl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000cdb91c05d4c4e5c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 4, 2022 at 12:14 AM Stefan Blachmann wrote: > On 1/4/22, Warner Losh wrote: > > Not without loading the xorg graphics stuff... graphics chips from the > last > > 15 or 20 years have lots of chip specific state that only the graphics > > stuff knows about... IIRC, it only knows about it because it put the > > graphics into a known state... it's the main reason laptops stopped > > suspending in the early 2000s... it looks to be a lot of work for a > > relatively rare use case... > > UEFI GOP seems to have the necessary functionalities > (https://wiki.osdev.org/GOP#Get_the_Current_Mode) so I guess the work > required would be limited (restore mode and redraw screen from > buffer). > UEFI GOP isn't available after we start the kernel, so this is a non-starter. It works great in the boot loader, but not so good after we boot. It could work for S3 sleep to disk where we actually reboot to restore the machine state, but we don't have sleep to disk today :( > With non-UEFI or old UGA UEFI implementations possibly one could use > the dual BIOS=C2=B4 CSM part. Just call the CSM BIOS init to set up GPU a= nd > the int 10h interface, and then set previously used mode+redraw. > BTW, doing that also could both enable vt(4) to change > modes/resolutions and using sc on UEFI computers. > Ah, if only things were really that simple... I tried variations on that hack years ago when suspending broke due to video. And it works for some machines, but not others, was the quick assessment I made. And the INT xx interface is unavailable on amd64 after we enter long mode (I tried this out on my then-current FreeBSD laptop which was 32 bit only, so 15 years ago?). Warner > But I think you are right, there are probably not too many users who > would make use of that. > > > On 1/4/22, Warner Losh wrote: > > On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann > > wrote: > > > >> Implementing S3 suspend/resume was a sponsored project itself. > >> However, it still does only work when at xorg graphics mode, which > >> already was topic in this thread. > >> When using it from console, no matter sc or vt, it still hangs with > >> dark screen and unresponsive keyboard. > >> Could finishing the suspend/resume work be sponsored, so that it also > >> works on console-only computers? > >> > > > > Not without loading the xorg graphics stuff... graphics chips from the > last > > 15 or 20 years have lots of chip specific state that only the graphics > > stuff knows about... IIRC, it only knows about it because it put the > > graphics into a known state... it's the main reason laptops stopped > > suspending in the early 2000s... it looks to be a lot of work for a > > relatively rare use case... > > > > Warner > > > > > >> On 12/30/21, Joseph Mingrone wrote: > >> > On Thu, 2021-12-30 at 14:15, Joseph Mingrone wrote= : > >> > > >> >> On Thu, 2021-12-30 at 08:05, =C3=96zkan KIRIK > >> >> wrote: > >> >>> I've ideas about enhancing the routing architecture. Is it possibl= e > >> >>> to > >> >>> add to wiki? > >> > > >> >> Certainly. Please do. > >> > > >> > The link again is https://wiki.freebsd.org/2021FoundationCFI > >> > > >> > >> > > > --000000000000cdb91c05d4c4e5c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 4, 2022 at 12:14 AM Stefa= n Blachmann <sblachmann@gmail.co= m> wrote:
On 1/4/22, Warner Losh <imp@bsdimp.com> wrote:
> Not without loading the xorg graphics stuff... graphics chips from the= last
> 15 or 20 years have lots of chip specific state that only the graphics=
> stuff knows about... IIRC, it only knows about it because it put the > graphics into a known state... it's the main reason laptops stoppe= d
> suspending in the early 2000s... it looks to be a lot of work for a > relatively rare use case...

UEFI GOP seems to have the necessary functionalities
(https://wiki.osdev.org/GOP#Get_the_Current_Mode)= so I guess the work
required would be limited (restore mode and redraw screen from
buffer).

UEFI GOP isn't available a= fter we start the kernel, so this is a non-starter.
It works = great in the boot loader, but not so good after we boot. It could work
for S3 sleep to disk where we actually reboot to restore the machine = state,
but we don't have sleep to disk today :(
=C2= =A0
With non-UEFI or old UGA UEFI implementations possibly one could use
the dual BIOS=C2=B4 CSM part. Just call the CSM BIOS init to set up GPU and=
the int 10h interface, and then set previously used mode+redraw.
BTW, doing that also could both enable vt(4) to change
modes/resolutions and using sc on UEFI computers.

=
Ah, if only things were really that simple...=C2=A0 I tried vari= ations on that
hack years ago when suspending broke due to video.= And it
works for some machines, but not others, was the quick as= sessment
I made. And the INT xx interface is unavailable on amd64= after we
enter long mode (I tried this out on my then-current Fr= eeBSD laptop
which was 32 bit only, so 15 years ago?).
=
Warner
=C2=A0
But I think you are right, there are probably not too many users who
would make use of that.


On 1/4/22, Warner Losh <imp@bsdimp.com> wrote:
> On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann <sblachmann@gmail.com>
> wrote:
>
>> Implementing S3 suspend/resume was a sponsored project itself.
>> However, it still does only work when at xorg graphics mode, which=
>> already was topic in this thread.
>> When using it from console, no matter sc or vt, it still hangs wit= h
>> dark screen and unresponsive keyboard.
>> Could finishing the suspend/resume work be sponsored, so that it a= lso
>> works on console-only computers?
>>
>
> Not without loading the xorg graphics stuff... graphics chips from the= last
> 15 or 20 years have lots of chip specific state that only the graphics=
> stuff knows about... IIRC, it only knows about it because it put the > graphics into a known state... it's the main reason laptops stoppe= d
> suspending in the early 2000s... it looks to be a lot of work for a > relatively rare use case...
>
> Warner
>
>
>> On 12/30/21, Joseph Mingrone <jrm@freebsd.org> wrote:
>> > On Thu, 2021-12-30 at 14:15, Joseph Mingrone <jrm@FreeBSD.= org> wrote:
>> >
>> >> On Thu, 2021-12-30 at 08:05, =C3=96zkan KIRIK <ozkan.kirik@gmail.com>
>> >> wrote:
>> >>> I've ideas about enhancing the routing architectu= re. Is it possible
>> >>> to
>> >>> add to wiki?
>> >
>> >> Certainly.=C2=A0 Please do.
>> >
>> > The link again is https://wiki.freebsd.org/2= 021FoundationCFI
>> >
>>
>>
>
--000000000000cdb91c05d4c4e5c2--